New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring-Boot 1.4 @ConfigurationProperties location deprecation effects #6220

gokhanoner opened this Issue Jun 24, 2016 · 7 comments


None yet
8 participants

gokhanoner commented Jun 24, 2016

I'm using a custom PropertySourceLoader to decrypt encryped properties via setting
org.springframework.boot.env.PropertySourceLoader factory.

It works for setting in file. For additional files, I normally use @ConfigurationProperties with setting location and it also works. But with 1.4, location parameter seem to be deprecated (it works for now). When I use @PropertySource to lod prop. file, it just load properties without decrypting them.

How can I make sure that all my property files are processed by org.springframework.boot.env.PropertySourceLoader factory? With the location parameter deprecated, I may need it soon.


This comment has been minimized.


philwebb commented Jun 24, 2016

As long as you can get the PropertySource into the Spring Environment @ConfigurationProperties should continue to work.

One option might be to set to a list of the files you want to load:

new SpringApplicationBuilder(Application.class)

If you want something more specific you could perhaps listen for ApplicationEnvironmentPreparedEvents or write a EnvironmentPostProcessor.

The listener approach would look like this:

new SpringApplicationBuilder(SanityCheckApplication.class)
    .listeners(new LoadAdditionalProperties())
public class LoadAdditionalProperties implements ApplicationListener<ApplicationEnvironmentPreparedEvent> {

    private ResourceLoader loader = new DefaultResourceLoader();

    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
        try {
            Resource resource = loader.getResource("");
            PropertySource<?> propertySource = new PropertySourcesLoader().load(resource);
        } catch (IOException ex) {
            throw new IllegalStateException(ex);


Alternatively, perhaps you could just put all your properties in the file and do away with the need to load additional files all together.


This comment has been minimized.

ccschneidr commented Nov 23, 2016

This solution has two drawbacks compared to the deprecated ConfigurationProperties.locations:

  • it is not regarded in integration tests and thus breaks them
  • it is not possible to add to the list via annotations in other modules/classes
    As already noted in #6726 it is not very convenient. Should there be an Annotation to contribute to config names?

This comment has been minimized.

EliuX commented Mar 30, 2017

What if I want to inject configurations in third modules using IoC? Before, every module had it's own configuration (yml|properties) and they didn't collide in the classpath. Now I must know each configuration name to load it from the application client?


This comment has been minimized.

augustodossantosti commented Apr 9, 2017

My project uses JWT authentication and its settings are in the application.yml file. Without using locations = "classpath: application.yml" the JWT settings are not loaded during the integration test. I do not understand why this option is depreciated.


This comment has been minimized.


wilkinsona commented Apr 10, 2017

@augustodossantosti What you have described should not be necessary. An integration test will load application.yml from the root of the classpath by default.


This comment has been minimized.

JuanCamiloRada commented Oct 2, 2017

@philwebb sorry I know is not related to issue discussion but some people (like me) do use this material as reference too, in your snipped you are annotating a instantiated class with no dependencies with @Component. What is the purpose of that?


This comment has been minimized.


wilkinsona commented Oct 2, 2017

@JuanCamiloRada It's redundant in this case as the listener is registered programatically:

new SpringApplicationBuilder(SanityCheckApplication.class)
    .listeners(new LoadAdditionalProperties())

I've edited Phil's answer to avoid further confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment