spring-boot: ConfigFileApplicationListener filtering fails when the defaultPropertySource is a composite
Prior to Boot 2.2.0 if you used spring-cloud-starter and within your bootstrap.yml set spring.config.name Boot would correctly load the property file specified in the property. Starting with Boot 2.2.0 this no longer works.
I have traced the breaking change down to this line added in commit d92c2f70230a6e30ccb5d5b51315062505ff74b6
In the situation I described above defaultProperties is actually an instance of ExtendedDefaultPropertySource defined here.
The sources property, which is a composite, contains the value of spring.config.name in this case. However in ConfigFileApplicationListener.replaceDefaultPropertySourceIfNecessary the code just calls .getSource to construct the new defaultProperties so we loose the properties in the composite and therefore the spring.config.name property is never retrieved.
For a sample that reproduces the problem you can look at this test.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 17 (12 by maintainers)
I’m able to reproduce this. As @ryanjbaxter mentioned, it’s because we use
defaultProperties.getSource()here. TheExtendedDefaultPropertySourceused by Spring Cloud has the property sources wrapped inside aCompositePropertySourceanddefaultProperties.getSource()just returns an empty map. We could change the filtering logic so that it only applies to Spring Boot’s default property source or only if the default property source is aMapPropertySource.I swear it worked in my IDE 😕
I’ve opened #17141 to look at the failing test. It feels like a different issue and the composite property source problem has been fixed so let’s keep this issue just for that one.
FWIW, it also fails for me when built locally with
./mvnw -U clean verify.@ryanjbaxter I’ve implemented the fix suggested by @mbhave, both Spring Cloud tests referenced in this issue work for me locally now.