Replace CompositePropertySource with one PropertySource per file

[philwebb]

See spring-projects/spring-boot#18174 for background and a sample application.

Raising an issue here as requested by @spencergibb

[ewiegs4]

Any chance of someone looking into this soon? I could take a stab at it if not but haven't worked in this code base before so it could take some time to get my bearings.

[ryanjbaxter]

@ewiegs4 if you want to take a shot at fixing the issue that would be great! @TYsewyn can help if you have any questions. Since the problem was in Greenwich as well, make sure you submit any PRs against the 2.1.x branch.

[ryanjbaxter]

@philwebb can you point us to how this behavior is implemented in Boot? We have multiple property sources due to the profile being enabled. We would want to combine them into a composite, but how come CompositeProperty source does not implement the expected list behavior (overriding the list property)?

[philwebb]

The IndexedElementsBinder class is the main area to look. Specifically, the bindIndexed method limits itself to one source at a time and returns as soon as binding works.

In Spring Boot 1.x we found that binding lists with profile specific files was quite confusing because it wasn't always clear when elements would be overridden (see this comment for an example).

In ConfigFileApplicationListener we register one PropertySource per file (see the addLoadedPropertySources method) which means they are adapted directly to individual ConfigurationPropertySource instances used by the Binder.

The Binder doesn't treat the CompositePropertySource in any special way, it's just a regular PropertySource as far as it's concerned. Because of this, the indexed binder will consider it as a single source and the early exit rule isn't being applied.

[ryanjbaxter]

I have confirmed that the same problem happens with just a normal config client (as opposed to using spring.cloud.config.server.bootstrap=true).

I am not really sure how we can solve this problem without introducing a breaking API change. The problem I believe lies in the PropertSourceLocator interface, who's locate method returns a single PropertySource. Since we may have multiple sources (ie multiple configuration files) we have to return a CompositePropertySource in our implementations.

I guess ideally we have a method that returns a List of PropertySources and we can add each one separately to the environment. We could add a default method to the API which does this and just have the default implementation call the existing locate method. Then override the default implementation in our PropertySourceLocator implementations.