Binding configuration properties to collection cannot replace individual items

This appears to be a regression in Spring Boot 2.0 (Spring Cloud Context relies on the old behaviour for rebinding to @ConfigurationProperties when the environment changes).

Start with a @ConfigurationProperties that has a List<String> called messages, and 2 items listed in application.properties (messages[0]=one, messages[1]=two). If you add a property source to the environment with messages[0]=foo you expect to be able to rebind and get [foo, two], but failing tests are showing [foo].

I haven’t had a chance to dig into what changed. Ignored the tests for now.

[wilkinsona]

I’m not convinced that we should encourage users to do this. Trying to override part of the configuration of a particular element of a list feels very brittle to me. If an earlier property source is changed such that a list has been reordered, or an element has been added before the one being targeted, then the configuration of the wrong item is going to be overridden. Completely overriding the contents of the list, which is now possible, is a much more robust solution and, IMO, is what we should promote.

[wilkinsona]

The current behaviour of using a single source for configuring the items in a list makes completely overriding the contents of a list easy and modifying a list, albeit with some tedious repetition, possible. The old behaviour of using multiple sources makes modifying a list easy and completely overriding the contents of a list impossible.

If we’re just picking between old vs new, I think the new approach is the clear winner. If we want to spend some more effort on this I think it should be post-M1 and it should focus on trying to avoid the repetition when modifying a list without hurting the ease with which a list can be overridden. Quite how we do that, I don’t know. It’ll probably require some new syntax and require us to look through every source whenever we’re binding a list in case there’s an “additive” property configured somewhere.