Support ConfigurationProperties property injection in constructors

[rgilles]

Thanks for reporting an issue for Micronaut, please review the task list below before submitting the
issue. Your issue report will be closed if the issue is incomplete and the below tasks not completed.

NOTE: If you are unsure about something and the issue is more of a question a better place to ask questions is on Stack Overflow (http://stackoverflow.com/tags/micronaut) or Gitter (https://gitter.im/micronautfw/). DO NOT use the issue tracker to ask questions.

Task List

• Steps to reproduce provided
• Stacktrace (if present) provided
• Example that reproduces the problem uploaded to Github
• Full description of the issue provided (see below)

Steps to Reproduce

1. clone the following repository: https://github.com/rgilles/mn-data-class-config.git
2. run mvn test
3. see the test in error

Bis

1. create a Kotlin data class annotated with @ConfigurationProperties
2. Inject the dataclass in the application or a test
3. you get the following error:

io.micronaut.context.exceptions.DependencyInjectionException: 
Failed to inject value for parameter [name] of class: mn.dataclass.config.MyConfig

Message: No bean of type [java.lang.String] exists. Ensure the class is declared a bean and if you are using Java or Kotlin make sure you have enabled annotation processing.
Path Taken: MyConfigTest.config --> new MyConfig([String name])
Caused by: io.micronaut.context.exceptions.NoSuchBeanException: No bean of type [java.lang.String] exists. Ensure the class is declared a bean and if you are using Java or Kotlin make sure you have enabled annotation processing.

Workaround:
Mix Java and Kotlin in the project and do the same thing but use Java POJO instead of Kotlin data class for the @ConfigurationProperties then it will works.

Expected Behaviour

@ConfigurationProperties should work with Kotlin data class as it works with Java POJO

Actual Behaviour

If you use @ConfigurationProperties on a Kotlin data class an exception is throw at runtime

Environment Information

• Operating System: Linux 4.15.0-48-generic Add profiles to CI and publish snapshots / releases #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
• Micronaut Version: 1.1.0
• JDK Version:

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Example Application

• https://github.com/rgilles/mn-data-class-config

[graemerocher]

The reason for this is Kotlin data classes use contructor arguments which currently cannot be injected with values. I think we should fix this, but we need to think how to do it since currently we allow injecting beans into constructor arguments and the issue is how to distinguish between a bean that is to be injected and a property value.

For example if you had data class MyConfig(val prop : String, val someBean : MyBean) how does one know which to apply value injection to and which to apply DI to?

[jameskleeh]

Workaround:
Mix Java and Kotlin in the project and do the same thing but use Java POJO instead of Kotlin data class for the @ConfigurationProperties then it will works.

You can use a normal Kotlin class instead of a data class. You don't have to use a Java POJO

[rgilles]

Thank you for the input.

[graemerocher]

Whilst we cannot change the current behaviour.

I think one thing we could do for this is allow @ConfigurationProperties to be declared on the constructor of a bean. In Java this would look like:

@Singleton
class FooProperties {
       @ConfigurationProperties("foo.bar")
        FooProperties(String one, int two) {
             ...
        }
}

In Kotlin it would probably have to be:

data class FooProperties @ConfigurationProperties("foo.bar") constructor(val one : String, val two : Int)

Unless we can come up with some way to detect it is a data class.

The other challenge is continuing to allow instances to be refreshable. Currently mutable properties can be refreshed, whilst with constructor injection that would not be possible unless we somehow recreate each instance.

[dave08]

There's no indication to identify data classes as far as I've seen people asking that on Kotlin Slack. But a hack could be to see if componentX functions are implemented for all constructor params... data classes automatically implement them, and I would suppose that one would not do that in Java or manually for such property classes...