Add @PropertySources annotation and support ignoreResourceNotFound [SPR-8371]

[spring-projects-issues]

Chris Beams opened SPR-8371 and commented

As of 3.1 M2, the @PropertySource annotation allows for declarative registration of property sources against the enclosing Environment. However, it does not allow for manipulation of property source ordering. This (if desired at all) must be done against the ConfigurableEnvironment#getPropertySources() MutablePropertySources API.

This issue exists to gauge interest in this feature (read: collect votes). Please be specific about use cases in order to assess whether such an enhancement truly represents a general need.

If interest is sufficient, we'll consider this for 3.1 RC1.

---

Affects: 3.1 M2

Issue Links:

• Allow for ignoreResourceNotFound on @PropertySource [SPR-10325] #14959 Allow for ignoreResourceNotFound on @PropertySource ("is duplicated by")
• Provide @Configuration support for PropertySource registration (@PropertySource) [SPR-8314] #12962 Provide @Configuration support for PropertySource registration (@PropertySource)
• Add "ignoreResourceNotFound" attribute to the @PropertySource [SPR-10932] #15560 Add "ignoreResourceNotFound" attribute to the @PropertySource

Referenced from: commits e95bd9e

12 votes, 17 watchers

[spring-projects-issues]

Benjamin Conlan commented

I would rather have the ordering be implicit (if possible) like so (this is based upon another feature I would like to see - that being that @PropertySource also allows for setIgnoreResourceNotFound method

@PropertySources({
  @PropertySource(value = "file:/etc/application/config.properties", ignoreResourceNotFound = true),
  @PropertySource(value = "file:/usr/local/etc/application/config.properties", ignoreResourceNotFound = true),
  @PropertySource(value = "file:conf/config.properties", ignoreResourceNotFound = true),
  @PropertySource(value = "classpath:application.properties")
})

In the above case the priority is the first entry which and continually falls back to others. In this case I would assume that if more than 1 configuration exists the first one resolved would set the properties leaving other property sources only the ability to add new properties (not modify those outlined by the one with higher priority. This still allows for multiple separate resources to be specified in a single @PropertySource with the same order priority. In this case I would hope that the properties be merged and overwritten based upon the reverse order specified ie:

@PropertySource({"classpath:custom.properties", "classpath:/default.properties"})

Would first resolve default.properties then overlay the custom.properties. (I think this might also already be the default behaviour?)

[spring-projects-issues]

Jack White commented

We have a project in which a default property value is set in a common package, but we then wish to overwrite that default value in another package that consumes the common package (the common package is consumed via @Import in the Configuration). Right now, the property value is being evaluated using the value from the inner (common) package first. Actually, the current order of evaluation seems to be the reverse of what it should be -- it appears that the system environment properties are evaluated first, then the imported properties, then the local properties.

[spring-projects-issues]

Chris Beams commented

@Jack, it would probably be worth putting together a small reproduction project (instructions) just to make sure everybody's on the same page about your scenario. I'd be happy to take a look at that and see if there's a way to do what you want, or if it's reasonable to implement something that will get there.

[spring-projects-issues]

Jack White commented

@Chris, I'll try to carve out some time to put that together.

[spring-projects-issues]

David Harkness commented

My situation is a little different. I have an inner class called Defaults that adds the main properties file. I then have a Dev class that subclasses Defaults and adds an overriding property file.

public class VendorConfig {
    @Configuration
    @PropertySource("classpath:/vendor.properties")
    static class Defaults { }

    @Configuration
    @Profile("dev")
    @PropertySource("classpath:/vendor-override.properties")
    static class Dev { }
}

The strange thing is that after making a small code change in a Hibernate model class, the subclass's properties suddenly stopped overriding those from the parent. This lead me to a solution of manually-reordering the overriding file. However, this feature request would make it easier.

Since I cannot put the sources in the same configuration, I would like to have the option to specify the name of another source that one should precede/override.

public class VendorConfig {
    @Configuration
    @PropertySource(name = "defaults", value = "classpath:/vendor.properties")
    static class Defaults { }

    @Configuration
    @Profile("dev")
    @PropertySource(name = "overrides", before = "defaults", value = "classpath:/vendor-override.properties")
    static class Dev { }
}

@Benjamine: How about "required = false" instead of "ignoreResourceNotFound = true" to mirror @Autowired?

[spring-projects-issues]

Benjamin Conlan commented

@davidharkness Yeah I'm impartial to syntax. I think your ordering mechanism is also far more intuitive than my idea of 'order sensitive annotations'.

[spring-projects-issues]

Phil Webb commented

As of Spring 4.0 you will now be able to repeat @PropertySource annotations when working with Java 8. For Java 6/7 a new @PropertySources annotation has been added.

Support for ignoreResourceNotFound as suggested by Benjamin Conlan has also been implemented.

[spring-projects-issues]

David Harkness commented

The @PropertySources annotation doesn't solve the ordering problem I mentioned above. Since this request has been resolved, should I create a new feature request for ordering separate @PropertySource annotations across multiple @Configuration classes?

[spring-projects-issues]

Phil Webb commented

Yes please raise a new issue for that. Thanks.

[spring-projects-issues]

will vuong commented

Can ignoreResourceNotFound be backported/merged into 3.2.x? This would be nice to have.

[spring-projects-issues]

Phil Webb commented

will vuong, As a general rule we only back-port bugs not improvements. Spring 4 is almost at RC stage so you shouldn't have too long to wait for this.