@PropertySource locations are being dropped in ConfigurationClassParser processPropertySource [SPR-11637]

[spring-projects-issues]

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 @PropertySource annotation 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 (@PropertySource processing fails)

Referenced from: commits ab24dda, 2187462, bd5b374, 0041e24

[spring-projects-issues]

Juergen Hoeller commented

I couldn't reproduce the exact scenario here but I managed to identify a likely potential root cause: In Spring 4.0, for named property sources with multiple values, the first of those values received the specified name but the others had resource-derived names... And the composite property source eventually received the specified name as well, being at odds with the first contained property source

Anyway, I've revised this for consistent naming of contained property sources, avoiding the potential for accidental overriding by name. This will be available in the next 4.0.4 snapshot. Let me know if any problem remains through simply reopening this issue accordingly.

Juergen