@PropertySource locations are being dropped in ConfigurationClassParser processPropertySource [SPR-11637] #16260
Description
Russ Tennant opened SPR-11637 and commented
After updating from Spring 3.2.8, property lookup via Environment broke for our projects.
Our projects defined a single property source on our main @Configuration class as follows.
@PropertySource(name="props",
value={
"classpath:/path/to/library/defaults.properties",
"classpath:/path/to/project/defaults.properties",
"${spring.properties}"
})
Previously, this would result in all three locations being searched in order (reverse) specified.
In Spring 4, only 2 locations are in the CompositePropertySource instead of the expected 3 locations.
It appears the lost location is discarded in ConfigurationClassParser.processPropertySource.
if (!StringUtils.hasText(name) || this.propertySources.containsKey(name)) {
// We need to ensure unique names when the property source will
// ultimately end up in a composite
ResourcePropertySource ps = new ResourcePropertySource(resource);
this.propertySources.add((StringUtils.hasText(name) ? name : ps.getName()), ps);
}
else {
this.propertySources.add(name, new ResourcePropertySource(name, resource));
}
It looks like the condition of the ternary operator should match the IF statement.
We have worked around the issue by using multiple @PropertySource annotations.
Affects: 4.0.3
Issue Links:
- @PropertySource annotation with multiple values and a name fails to register all property sources [SPR-9127] #13766
@PropertySourceannotation with multiple values and a name fails to register all property sources - PropertySource named cannot be added relative to itself (@PropertySource processing fails) [SPR-12115] #16731 PropertySource named cannot be added relative to itself (
@PropertySourceprocessing fails)