org.springframework.context.annotation

## Annotation Type PropertySource

    @Target(value=TYPE)
    @Retention(value=RUNTIME)
    @Documented
    public @interface PropertySource

Annotation providing a convenient and declarative mechanism for adding a `PropertySource` to Spring's `Environment`. To be used in conjunction with @`Configuration` classes.

### 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`, one must register a `PropertySourcesPlaceholderConfigurer`. This happens automatically when using `<context:property-placeholder>` in XML, but must be explicitly registered using a `static` `@Bean` method when using `@Configuration` classes. See the "Working with externalized values" section of @`Configuration` Javadoc and "a note on BeanFactoryPostProcessor-returning @Bean methods" of @`Bean` Javadoc for details and examples.

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

Any ${...} placeholders present in a `@PropertySource` resource 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 `@ProperySource` 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` Javadoc for details.

Since:
  3.1
Author:
  Chris Beams
See Also:
  `Configuration`, `PropertySource`, `ConfigurableEnvironment.getPropertySources()`, `MutablePropertySources`

### Required Element Summary

Required Elements
`String[]` `value` Indicate the resource location(s) of the properties file to be loaded.

### Optional Element Summary

Optional Elements
`String` `name` Indicate the name of this property source.

### Element Detail

#### value

    public abstract String[] value

Indicate the resource location(s) of the properties file to be loaded. For example, `"classpath:/com/myco/app.properties"` or `"file:/path/to/file"`.

Resource location wildcards (e.g. **/*.properties) are not permitted; each location must evaluate to exactly one `.properties` resource.

${...} placeholders will be resolved against any/all property sources already registered with the `Environment`. See above for examples.

Each location will be added to the enclosing `Environment` as its own property source, and in the order declared.

#### name

    public abstract String name

Indicate the name of this property source. If omitted, a name will be generated based on the description of the underlying resource.

See Also:
  `PropertySource.getName()`, `Resource.getDescription()`

Default:
  ""