Constructor-based configuration property binding fails silently when parameter name information is not available

[thekalinga]

I tried using @ConfigurationProperties with an immutable class, but the object has all values set to default null values

I used 2.2.0-BUILD-SNAPSHOT version to test this

Please find the test project in the attachment

spring-boot-playground.zip

[wilkinsona]

Thanks for the sample. Unfortunately, I haven't been able to reproduce the behaviour that you have described. Here's the output from running ./gradlew bootRun:

[$]: ./gradlew bootRun

> Task :bootRun

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::  (v2.2.0.BUILD-SNAPSHOT)

2019-05-21 14:24:36.138  INFO 99177 --- [           main] com.acme.playground.DemoApplication      : Starting DemoApplication on Andys-MacBook-Pro.local with PID 99177 (/Users/awilkinson/Downloads/spring-boot-playground/build/classes/java/main started by awilkinson in /Users/awilkinson/Downloads/spring-boot-playground)
2019-05-21 14:24:36.140  INFO 99177 --- [           main] com.acme.playground.DemoApplication      : No active profile set, falling back to default profiles: default
2019-05-21 14:24:36.551  INFO 99177 --- [           main] com.acme.playground.DemoApplication      : Config: ExternalSystemConfig(username=alpha, password=password, timeoutInSecs=2)
2019-05-21 14:24:36.636  INFO 99177 --- [           main] com.acme.playground.DemoApplication      : Started DemoApplication in 0.781 seconds (JVM running for 1.057)

As you can see, username, password, and timeoutInSecs are all non-null.

Can you please describe the steps that must be taken with the sample to reproduce the behaviour that you have described?

[allanneves]

Hi @thekalinga, @wilkinsona
I opened the project in IntelliJ IDEA and was able to replicate it. I do not know what causes the binding to fail in IntelliJ but it may be related to Lombok and Annotation processing. The app ran perfectly on the terminal in all attempts:

However, when I switched to IntelliJ it kept failing. I made that work in IntelliJ using Lombok and enabling Annotation Processing only after commenting out the @builder and @AllArgsConstructor annotations and adding a @Setter to it:

Please check if that is your case. I hope that helps.

Regards,
Allan

[thekalinga]

@allanneves @wilkinsona Thanks for these two observations

Yes.. Looks like the issue has something to do with Intellij. I went to intellij settings & delegated build actions to gradle & the application works as expected. If I uncheck this box & run the app with intellij, then issue is consistently reproducible

[thekalinga]

This is the setting I am referring to

[thekalinga]

Raised an issue against intellij

https://youtrack.jetbrains.com/issue/IDEA-214730

[philwebb]

I'm going to reopen this just to check that there's not a work-around that we can put in place.

[wilkinsona]

Thank you, @allanneves and @thekalinga. I've reproduced the problem in IntelliJ IDEA.

The cause is the names of the constructor parameters which are arg0, arg1, and arg2. Adding -parameters as an additional command line parameter to the compiler configuration fixes the problem. It does not occur when building with Gradle as Spring Boot's Gradle plugin automatically adds -parameters to all CompileJava tasks. This configuration isn't picked up by the IDE when importing the project, hence the problem being specific to compiling and running in the IDE.

We should see if we can improve the diagnostics in the ConstructorParametersBinder to detect when parameter name information is not available. We should also improve the documentation to note the need for -parameters as we already do for endpoint operations.

[wilkinsona]

I've switched to using DefaultParameterNameDiscoverer which aligns with parameter name discovery for actuator endpoint operations. This means that -parameters won't strictly be necessary as it delegates to LocalVariableTableParameterNameDiscoverer which will read debug information from the .class file if the names are not available via standard reflection.

[thekalinga]

@wilkinsona Does this work with @ConstructorProperties({....})?

[wilkinsona]

No, I don't believe it does. If that's something that you think Framework's parameter name discovery should take into consideration, please open a Framework issue.

[thekalinga]

@wilkinsona Will open an issue. Thanks