Avoid setting @ConfigurationProperties property with default value to null when undefined

[sdeleuze]

I got an issue reported by @herder with a repro project mentioning that Spring Boot sets the @ConfigurationProperties properties to null when there is no value defined in application.properties instead of leaving the default value from the constructor.

This does not work well with Kotlin non-nullable types and default arguments.

I can help working on a fix.

[snicoll]

@sdeleuze I am not following and that sample is rather involved with no readme. What you are describing is kotlin specific I assume (we don't do such thing in Java as far as I know). If that's the case, worth mentioning....

[herder]

that sample is rather involved with no readme.

True... :)

I've added some actual tests to the project now, and added a Readme.

[snicoll]

@sdeleuze we'd probably need you to review the sample and report here again once we've narrow down the issue. This is not Spring Boot specific and I don't know kotlin enough to figure out where the issue is coming from. However, I can explain why this is happening.

That sample has a @Validated annotation on it which is going to create a CGLIB proxy around the class. There is a ValidationAutoConfiguration that triggers a MethodValidationPostProcessor and that processor will be responsible to create the proxy. On a cglib proxy all fields are null (default value). With a Java-based cglib proxy you'll call the methods which will invoke the underlying class and all is fine. With a kotlin-based cglib proxy, it looks like the getter isn't invoked and the field (on the proxy!) is directly invoked. That doesn't sound right at all.

So I am afraid it's a cglib/kotlin incompatiblity and nothing we can fix. Spring Boot doesn't bind to null (you can debug ConfigurationPropertiesBindingPostProcessor and you'll see the two @ConfigurationProperties beans are bound exactly the same way.

@herder if I exclude the ValidationAutoConfiguration the cglib proxy goes away and your test passes.

[sdeleuze]

@snicoll Ok thanks for your feedback I will have a deeper look.

[herder]

Have you had a chance to look further into this, @sdeleuze ?

[sdeleuze]

Yes I think #8762 will fix your issue when it will be resolved so please follow this issue.