Spring-Boot 1.4 @ConfigurationProperties location deprecation effects

[gokhanoner]

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

It works for setting in application.properties 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.

[philwebb]

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

One option might be to set spring.config.name to a list of the files you want to load:

new SpringApplicationBuilder(Application.class)
    .properties("spring.config.name=application,mine")
    .run(args);

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())
    .run(args);

public class LoadAdditionalProperties implements ApplicationListener<ApplicationEnvironmentPreparedEvent> {

    private ResourceLoader loader = new DefaultResourceLoader();

    @Override
    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
        try {
            Resource resource = loader.getResource("classpath:mine.properties");
            PropertySource<?> propertySource = new PropertySourcesLoader().load(resource);
            event.getEnvironment().getPropertySources().addLast(propertySource);
        } catch (IOException ex) {
            throw new IllegalStateException(ex);
        }
    }

}

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

[ccschneidr]

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?

[EliuX]

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?

[augustodossantosti]

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.

[wilkinsona]

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

[JuanCamiloRada]

@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?

[wilkinsona]

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

new SpringApplicationBuilder(SanityCheckApplication.class)
    .listeners(new LoadAdditionalProperties())
    .run(args);

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