Provide configuration property metadata for binding to Map<String, RichType> and List<RichType>

[wilkinsona]

One example of such a Map is in Spring Cloud stream. As things stand, there's no metadata for any of the properties on BindingProperties. I think it would be interesting to explore the possibility of providing metadata for those properties, perhaps using a wildcard for the key in the map:

spring.cloud.stream.bindings.*.content-type
spring.cloud.stream.bindings.*.destination
spring.cloud.stream.bindings.*.group
…

For this to be useful, we'd need a corresponding enhancement in each of the IDE plugins.

[snicoll]

I've thought long and hard about this and I don't think we should do this (See also #9894). There are several reasons:

1. Scalar vs. Group: the only way for us to harvest nested object is by using @NestedConfigurationProperty (essentially, this is not a scalar value, please create a "sub-group" for all the properties defined by that type). If we support that for collections or maps now, how do we tell if the value is scalar or not?
2. Scope: if we find a way to fix this and we offer automatic harvesting of POJOs, where do we stop? The next step is to expect this to be somehow recursive (BindingProperties may hold another nested object).
3. Duplication: the use of the * above is what I ended up considering myself but that pojo can be used in multiple places, in multiples maps and/or in different objects. It means that the metadata is duplicated. If you don't want that, we need a third root objects (to harvest the pojo) and a way to reference to it somehow).

Let's see what the rest of the team thinks.

[philwebb]

For "1)" the @NestedConfigurationProperty could be the indicator that the value isn't a scalar. So @NestedConfigurationProperty Map<String, Foo> is a hint that Foo can be expanded with the * syntax, where as @NestedConfigurationProperty Map<String, Foo> cannot (and we expect to be able to convert a String to a Foo somehow.

For "2)" and "3)" I'd probably go with duplicate *. I don't see the duplication being all that much of a problem, as long as there isn't an infinite loop (e.g. Foo contains a Map<String,Foo>).

[philwebb]

FWIW, I think we shouldn't invest too much time thinking about this until after 2.0.

[snicoll]

and we expect to be able to convert a String to a Foo somehow.

That would break backward compatibility but I think having to add an annotation to ask the AP to "expand" is a nice way to solve the scope problem. Great idea! So 1) and 2) could be fixed by some signals that the AP should expand the metadata (and the binding should work as it does now, regardless of the annotation). That's pretty much what happens today for @NestedConfigurationProperty anyway.

As for 3, duplication is much easier but we need some feedback from IDE developers first IMO (ping @YannCebron @kdvolder and @AlexFalappa).

(By the way, I am kind of changing my mind because I realized recently there is no way to add hints for those types and implementing this would be a nice way to fix that).

[wilkinsona]

Since this issue was raised, the IDEs have plugged the gap to varying degrees. A new gap will appear if we add support for immutable configuration properties that use constructor injection. Without metadata, they'd have to plug that gap and look at the constructor rather than the property setters to figure out what properties to offer.