Document that @ConstructorBinding should be set explicitly for non-inner classes

[fkowal]

Here what happened to be during bumping spring-boot from 2.2.0 to 2.2.1 migration

I was using kotlin with +- such a configuration

@Configuration
@EnableConfigurationProperties(XXProperties::class)
class XXConfiguration {
}

@ConfigurationProperties(prefix = "xxprefix")
@ConstructorBinding
data class XXProperties(arg1: Arg1Class)

data class Arg1Class(moreargs: String)

Now i am getting

Failed to bind properties under 'xxprefix' to org.example.XXProperties:

    Reason: Parameter specified as non-null is null: method org.example.XXProperties.<init>, parameter arg1

I am a bit confused about what changed and how to undo the changes from 2.2.1.
I was thinking that it might be related to #18674, but i am not sure.

[philwebb]

Does adding @ConstructorBinding to the Arg1Class fix the issue? If not, could you please provide a small sample application.

[snicoll]

Thanks for creating the issue. It isn't related to #18674. Actually, this arrangement worked so far by accident and we cleaned things up in 2.2.1 on purpose. Previously, if a top-level configuration properties was using constructor binding, any element that's part of the constructor (including classes that are defined outside of the top-level object) was also using constructor binding. We believe this is wrong as you may chose to use constructor binding for certain parts but not for all.

If your "sub-type" is an inner class of your top-level class and you're using constructor binding, this will be the mechanism for it too. If your "sub-type" is not an inner class, you'll have to tell the binder if you want to opt-in to constructor binding.

Based on your partial code snippet, if you make Arg1Class an inner class of XXProperties things will work without an extra @ConstructorBinding. If you want to keep Arg1Class separate, you need to add @ConstructorBinding.

Having said all that, there is an opportunity to mention that behaviour explicitly in the documentation.

[fkowal]

Let me verify, and get back with feedback

For now i can already write that the app is split into multiple modules

modules/domainA
modules/domainB
app

modules have no dependency on spring
only app is a spring boot applicatication

and so far it was very convenient that i having a application.yaml looking somewhat like

domainA:
   ...

domainB:
  ...

• app/src/../DomainAConfiguration.kt

@ConstructorBinding
@ConfigurationProperties(prefix = "domainA")
data class DomainAProperties( ... here go data classes from moduleA )
// the above property class uses spring annotations

it was very convenient (for configuration loading purposes) to create a single wrapper type with a prefix defined
but it's arguments would be standard data/configuration objects from other modules

it seems that now i will need to duplicate all the configuration classes from all modules
this would be most annoying

i'll verify and get back to u with feedback

[fkowal]

I verified and it is as @snicoll has written

@ConstructorBinding
data class XXProps(yyProps: YYProps) {
  data class YYProps(...) // these work without additional annotations
}

// this would require @ConstructorBinding
data class YYProps(...)

So in my case since I am embedding props from springless modules i had to make a copy of the whole data class hierarchy from an external module and to provide a mapping between spring property classes to module classes

i tried
@ConstructorBinding
data class XXProp(
  @ConstructorBinding // but this annotation is not allowed on properties
  val yyProp: YYProp
)

Thank you for providing me with guidance to fix my problem.
I suspect that the use-case I have described might be quite common.

If I could suggest providing some way to support this use-case ie. in a way I described above (adding the PARAMETER to supported @Target for the @ConstructorBinding) it would be most appreciated.

[philwebb]

@fkowal I've raised #18935 to consider what we can do about that use-case.

[mbhave]

I think we can close this issue since we've decided to treat any nested binding of a @ConstructorBinding type as @ConstructorBinding, even if the type is not a nested type. Any changes made as part of #18935 can be documented in that issue itself.