|
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