Spring PropertyPlaceholderConfigurer и контекст: свойство-placeholder
У меня есть объявление bean:
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>WEB-INF/classes/config/properties/database.properties</value>
<value>classpath:config/properties/database.properties</value>
</list>
</property>
<property name="ignoreResourceNotFound" value="true"/>
</bean>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="${jdbc.driverClassName}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
</bean>
Теперь я хочу изменить выше PropertyPlaceholderConfigurer в следующем формате:
<context:component-scan base-package="org.example.config"/>
<util:properties id="jdbcProperties"
location="classpath:config/properties/database.properties"/>
- ignoreResourceNotFound игнорирует свойство во время работы. например:
При тестировании приложения WEB-INF/.. путь игнорируется (поскольку maven
файл проекта и свойства находится под src/main/resources/..), тогда как
запуск веб-приложения, другое свойство будет игнорировать путь, мне нужно
для реализации того же формата.
- должен иметь возможность добавлять несколько файлов свойств, например
database.properties, test.properties и т.д.
- в Spring 3, я могу использовать аннотацию вместо этих xml файлов для DB
загрузка, как я могу это сделать? так как я использую только один XML файл (данный
выше) для загрузки данных db.
Я использую Spring 3 framework.
Ответы
Ответ 1
<context:property-placeholder ... />
является XML-эквивалентом PropertyPlaceholderConfigurer. Поэтому, предпочтете это. <util:properties/>
просто запустил экземпляр java.util.Properties, который вы можете ввести.
В Spring 3.1 (не 3.0...) вы можете сделать что-то вроде этого:
@Configuration
@PropertySource("/foo/bar/services.properties")
public class ServiceConfiguration {
@Autowired Environment environment;
@Bean public javax.sql.DataSource dataSource( ){
String user = this.environment.getProperty("ds.user");
...
}
}
В Spring 3.0 вы можете "получить доступ" к свойствам, определенным с помощью механизма PropertyPlaceHolderConfigurer, используя аннотации SpEl:
@Value("${ds.user}") private String user;
Если вы хотите удалить XML все вместе, просто зарегистрируйте PropertyPlaceholderConfigurer вручную, используя конфигурацию Java. Я предпочитаю подход 3.1. Но если вы используете подход Spring 3.0 (поскольку 3.1 не GA еще...), вы можете теперь определить вышеупомянутый XML следующим образом:
@Configuration
public class MySpring3Configuration {
@Bean
public static PropertyPlaceholderConfigurer configurer() {
PropertyPlaceholderConfigurer ppc = ...
ppc.setLocations(...);
return ppc;
}
@Bean
public class DataSource dataSource(
@Value("${ds.user}") String user,
@Value("${ds.pw}") String pw,
...) {
DataSource ds = ...
ds.setUser(user);
ds.setPassword(pw);
...
return ds;
}
}
Обратите внимание, что PPC определяется с помощью метода определения static
bean. Это необходимо для того, чтобы убедиться, что bean зарегистрирован раньше, потому что PPC является BeanFactoryPostProcessor
- он может влиять на регистрацию beans самих себя в контексте, поэтому он обязательно должен быть зарегистрирован перед всем остальным.
Ответ 2
Во-первых, вам не нужно определять оба этих местоположения. Просто используйте classpath:config/properties/database.properties
. В WAR WEB-INF/classes
- это запись в classpath, поэтому она будет работать нормально.
После этого я думаю, что вы хотите, чтобы вы использовали Spring конфигурацию на основе схемы для создания конфигуратора. Это будет выглядеть следующим образом:
<context:property-placeholder location="classpath:config/properties/database.properties"/>
Обратите внимание, что вам больше не нужно "ignoreResourceNotFound". Если вам нужно определить свойства отдельно, используя util:properties
:
<context:property-placeholder properties-ref="jdbcProperties" ignore-resource-not-found="true"/>
Как правило, нет никаких оснований определять их отдельно.