Annotation Type PropertySource

Example usage

Given a file app.properties containing the key/value pair testbean.name=myTestBean, the following @Configuration class uses @PropertySource to contribute app.properties to the Environment's set of PropertySources.

 @Configuration
 @PropertySource("classpath:/com/myco/app.properties")
 public class AppConfig {

     @Autowired
     Environment env;

     @Bean
     public TestBean testBean() {
         TestBean testBean = new TestBean();
         testBean.setName(env.getProperty("testbean.name"));
         return testBean;
     }
 }

Notice that the Environment object is @Autowired into the configuration class and then used when populating the TestBean object. Given the configuration above, a call to testBean.getName() will return "myTestBean".

Resolving ${...} placeholders in <bean> and @Value annotations

In order to resolve ${...} placeholders in <bean> definitions or @Value annotations using properties from a PropertySource, you must ensure that an appropriate embedded value resolver is registered in the BeanFactory used by the ApplicationContext. This happens automatically when using <context:property-placeholder> in XML. When using @Configuration classes this can be achieved by explicitly registering a PropertySourcesPlaceholderConfigurer via a static@Bean method. Note, however, that explicit registration of a PropertySourcesPlaceholderConfigurer via a static@Bean method is typically only required if you need to customize configuration such as the placeholder syntax, etc. See the "Working with externalized values" section of @Configuration's javadocs and "a note on BeanFactoryPostProcessor-returning @Bean methods" of @Bean's javadocs for details and examples.

Resolving ${...} placeholders within @PropertySource resource locations

Any ${...} placeholders present in a @PropertySourceresource location will be resolved against the set of property sources already registered against the environment. For example:

 @Configuration
 @PropertySource("classpath:/com/${my.placeholder:default/path}/app.properties")
 public class AppConfig {

     @Autowired
     Environment env;

     @Bean
     public TestBean testBean() {
         TestBean testBean = new TestBean();
         testBean.setName(env.getProperty("testbean.name"));
         return testBean;
     }
 }

Assuming that "my.placeholder" is present in one of the property sources already registered, e.g. system properties or environment variables, the placeholder will be resolved to the corresponding value. If not, then "default/path" will be used as a default. Expressing a default value (delimited by colon ":") is optional. If no default is specified and a property cannot be resolved, an IllegalArgumentException will be thrown.

A note on property overriding with @PropertySource

In cases where a given property key exists in more than one .properties file, the last @PropertySource annotation processed will 'win' and override.

For example, given two properties files a.properties and b.properties, consider the following two configuration classes that reference them with @PropertySource annotations:

 @Configuration
 @PropertySource("classpath:/com/myco/a.properties")
 public class ConfigA { }

 @Configuration
 @PropertySource("classpath:/com/myco/b.properties")
 public class ConfigB { }
 

The override ordering depends on the order in which these classes are registered with the application context.

 AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
 ctx.register(ConfigA.class);
 ctx.register(ConfigB.class);
 ctx.refresh();
 

In the scenario above, the properties in b.properties will override any duplicates that exist in a.properties, because ConfigB was registered last.

In certain situations, it may not be possible or practical to tightly control property source ordering when using @PropertySource annotations. For example, if the @Configuration classes above were registered via component-scanning, the ordering is difficult to predict. In such cases - and if overriding is important - it is recommended that the user fall back to using the programmatic PropertySource API. See ConfigurableEnvironment and MutablePropertySources javadocs for details.

NOTE: This annotation is repeatable according to Java 8 conventions. However, all such @PropertySource annotations need to be declared at the same level: either directly on the configuration class or as meta-annotations within the same custom annotation. Mixing of direct annotations and meta-annotations is not recommended since direct annotations will effectively override meta-annotations.