|  | 
| 54 | 54 |  *     } | 
| 55 | 55 |  * }</pre> | 
| 56 | 56 |  * | 
| 57 |  | - * Notice that the {@code Environment} object is | 
|  | 57 | + * <p>Notice that the {@code Environment} object is | 
| 58 | 58 |  * {@link org.springframework.beans.factory.annotation.Autowired @Autowired} into the | 
| 59 | 59 |  * configuration class and then used when populating the {@code TestBean} object. Given | 
| 60 | 60 |  * the configuration above, a call to {@code testBean.getName()} will return "myTestBean". | 
| 61 | 61 |  * | 
| 62 |  | - * <h3>Resolving ${...} placeholders in {@code <bean>} and {@code @Value} annotations</h3> | 
| 63 |  | - * | 
| 64 |  | - * In order to resolve ${...} placeholders in {@code <bean>} definitions or {@code @Value} | 
| 65 |  | - * annotations using properties from a {@code PropertySource}, one must register | 
| 66 |  | - * a {@code PropertySourcesPlaceholderConfigurer}. This happens automatically when using | 
| 67 |  | - * {@code <context:property-placeholder>} in XML, but must be explicitly registered using | 
| 68 |  | - * a {@code static} {@code @Bean} method when using {@code @Configuration} classes. See | 
| 69 |  | - * the "Working with externalized values" section of @{@link Configuration}'s javadoc and | 
| 70 |  | - * "a note on BeanFactoryPostProcessor-returning @Bean methods" of @{@link Bean}'s javadoc | 
| 71 |  | - * for details and examples. | 
|  | 62 | + * <h3>Resolving <code>${...}</code> placeholders in {@code <bean>} and {@code @Value} annotations</h3> | 
|  | 63 | + * | 
|  | 64 | + * <p>In order to resolve ${...} placeholders in {@code <bean>} definitions or {@code @Value} | 
|  | 65 | + * annotations using properties from a {@code PropertySource}, you must ensure that an | 
|  | 66 | + * appropriate <em>embedded value resolver</em> is registered in the {@code BeanFactory} | 
|  | 67 | + * used by the {@code ApplicationContext}. This happens automatically when using | 
|  | 68 | + * {@code <context:property-placeholder>} in XML. When using {@code @Configuration} classes | 
|  | 69 | + * this can be achieved by explicitly registering a {@code PropertySourcesPlaceholderConfigurer} | 
|  | 70 | + * via a {@code static} {@code @Bean} method. Note, however, that explicit registration | 
|  | 71 | + * of a {@code PropertySourcesPlaceholderConfigurer} via a {@code static} {@code @Bean} | 
|  | 72 | + * method is typically only required if you need to customize configuration such as the | 
|  | 73 | + * placeholder syntax, etc. See the "Working with externalized values" section of | 
|  | 74 | + * {@link Configuration @Configuration}'s javadocs and "a note on | 
|  | 75 | + * BeanFactoryPostProcessor-returning {@code @Bean} methods" of {@link Bean @Bean}'s | 
|  | 76 | + * javadocs for details and examples. | 
| 72 | 77 |  * | 
| 73 | 78 |  * <h3>Resolving ${...} placeholders within {@code @PropertySource} resource locations</h3> | 
| 74 | 79 |  * | 
| 75 |  | - * Any ${...} placeholders present in a {@code @PropertySource} {@linkplain #value() | 
|  | 80 | + * <p>Any ${...} placeholders present in a {@code @PropertySource} {@linkplain #value() | 
| 76 | 81 |  * resource location} will be resolved against the set of property sources already | 
| 77 | 82 |  * registered against the environment. For example: | 
| 78 | 83 |  * | 
|  | 
| 92 | 97 |  *     } | 
| 93 | 98 |  * }</pre> | 
| 94 | 99 |  * | 
| 95 |  | - * Assuming that "my.placeholder" is present in one of the property sources already | 
|  | 100 | + * <p>Assuming that "my.placeholder" is present in one of the property sources already | 
| 96 | 101 |  * registered, e.g. system properties or environment variables, the placeholder will | 
| 97 | 102 |  * be resolved to the corresponding value. If not, then "default/path" will be used as a | 
| 98 | 103 |  * default. Expressing a default value (delimited by colon ":") is optional.  If no | 
|  | 
| 101 | 106 |  * | 
| 102 | 107 |  * <h3>A note on property overriding with @PropertySource</h3> | 
| 103 | 108 |  * | 
| 104 |  | - * In cases where a given property key exists in more than one {@code .properties} | 
|  | 109 | + * <p>In cases where a given property key exists in more than one {@code .properties} | 
| 105 | 110 |  * file, the last {@code @PropertySource} annotation processed will 'win' and override. | 
| 106 | 111 |  * | 
| 107 |  | - * For example, given two properties files {@code a.properties} and | 
|  | 112 | + * <p>For example, given two properties files {@code a.properties} and | 
| 108 | 113 |  * {@code b.properties}, consider the following two configuration classes | 
| 109 | 114 |  * that reference them with {@code @PropertySource} annotations: | 
| 110 | 115 |  * | 
|  | 
| 118 | 123 |  * public class ConfigB { } | 
| 119 | 124 |  * </pre> | 
| 120 | 125 |  * | 
| 121 |  | - * The override ordering depends on the order in which these classes are registered | 
|  | 126 | + * <p>The override ordering depends on the order in which these classes are registered | 
| 122 | 127 |  * with the application context. | 
| 123 | 128 |  * | 
| 124 | 129 |  * <pre class="code"> | 
|  | 
| 128 | 133 |  * ctx.refresh(); | 
| 129 | 134 |  * </pre> | 
| 130 | 135 |  * | 
| 131 |  | - * In the scenario above, the properties in {@code b.properties} will override any | 
|  | 136 | + * <p>In the scenario above, the properties in {@code b.properties} will override any | 
| 132 | 137 |  * duplicates that exist in {@code a.properties}, because {@code ConfigB} was registered | 
| 133 | 138 |  * last. | 
| 134 | 139 |  * | 
|  | 
| 150 | 155 |  * @author Chris Beams | 
| 151 | 156 |  * @author Juergen Hoeller | 
| 152 | 157 |  * @author Phillip Webb | 
|  | 158 | + * @author Sam Brannen | 
| 153 | 159 |  * @since 3.1 | 
| 154 | 160 |  * @see PropertySources | 
| 155 | 161 |  * @see Configuration | 
|  | 
0 commit comments