@PropertySource annotation with multiple values and a name fails to register all property sources [SPR-9127]

[spring-projects-issues]

Patrick Marschik opened SPR-9127 and commented

When you create an annotation based configuration class with a @PropertySource annotation that provides multiple .properties files and a name for that property source only one property source gets registered since all ResourcePropertySource s have the same name and thus get overwritten by the subsequent property sources.

Example:

@Configuration
@PropertySource(name = "someName", value = {"classpath:a.properties", "classpath:b.properties"})
public class MyConfiguration {
}

this will only register b.properties in the Environment since 2 ResourcePropertySources with the name someName are created and added to the environment.

---

Affects: 3.1 GA

Issue Links:

• Resolving ${} system properties in @PropertySource annotation does not work anymore [SPR-9380] #14016 Resolving ${} system properties in @PropertySource annotation does not work anymore ("is duplicated by")
• Fix regression in @PropertySource placeholder resolution [SPR-9133] #13772 Fix regression in @PropertySource placeholder resolution
• @PropertySource locations are being dropped in ConfigurationClassParser processPropertySource [SPR-11637] #16260 @PropertySource locations are being dropped in ConfigurationClassParser processPropertySource

Referenced from: commits 4df2a14, e30d610, 41ade68

[spring-projects-issues]

Juergen Hoeller commented

Sounds like a trivial enough fix for 3.1.1 still, Chris?

[spring-projects-issues]

Chris Beams commented

commit 41ade68b50b39485b3cf02b9c6fb8eb74962146b
Author: Chris Beams <cbeams@vmware.com>
Date:   Thu Feb 16 16:43:28 2012 +0100

    Fix @PropertySource bug with multiple values
    
    Prior to this commit, specifying a named @PropertySource with multiple
    values would not work as expected. e.g.:
    
      @PropertySource(
          name = "ps",
          value = { "classpath:a.properties", "classpath:b.properties" })
    
    In this scenario, the implementation would register a.properties with
    the name "ps", and subsequently register b.properties with the name
    "ps", overwriting the entry for a.properties.
    
    To fix this behavior, a CompositePropertySource type has been introduced
    which accepts a single name and a set of PropertySource objects to
    iterate over. ConfigurationClassParser's @PropertySource parsing routine
    has been updated to use this composite approach when necessary, i.e.
    when both an explicit name and more than one location have been
    specified.
    
    Note that if no explicit name is specified, the generated property
    source names are enough to distinguish the instances and avoid
    overwriting each other; this is why the composite wrapper is not used
    in these cases.
    
    Issue: SPR-9127