Spring замена собственности на испытания и производство
Я столкнулся с этим для замены свойств в spring
<context:property-placeholder location="esb-project-config.properties"/>
но, к сожалению, мы не хотим этого в XML файле, так как мы хотим повторно использовать этот файл в наших тестах, но поменяем файл test.properties для теста. то есть. мы хотим протестировать все производственные привязки, но со свойствами, подходящими для тестирования, например, для localhost. Как мы можем загрузить ApplicationContext, но с разными файлами свойств?
спасибо,
Дин
Ответы
Ответ 1
Поместите конфигурацию-заполнителя в дополнительный файл конфигурации spring xml.
Например:
-
applicationContext.xml
- для нормальной конфигурации без конфигурации свойств-заполнителя
-
applicationContext-config.xml
- содержит только файл-заполнитель, который загружает производственный конфигурационный файл.
-
testApplicationContext.xml
. Этот файл include
applicationContext.xml
и использует свойство-placeholder с другим файлом свойств.
В веб-приложении вы можете загрузить все производственные файлы spring с этим шаблоном applicationContext*.xml
.
Для тестов вам нужно только загрузить testApplicationContext.xml
, это будет включать обычную конфигурацию, но с другими свойствами.
Ответ 2
несколько подходов:
1. Свойство "Заказ"
in src/main/resources/your-conf.xml
<context:property-placeholder
location="classpath:esb-project-config.properties"
order="1"/>
in src/test/resources/your-test-config.xml
<context:property-placeholder
location="classpath:esb-project-config.properties"
order="0"/>
Если вы выполняете тест с src/test/resources
как путь к тестовому классу, приведенное выше будет обеспечивать отмену src/main/resources/esb-project-config.properties
с помощью src/test/resources/esb-project-config.properties
.
Это приведет к переопределению всего property-placeholder
, хотя вам нужно будет предоставить все свойства, необходимые вашему приложению для этого теста property-placeholder
. например.
<context:property-placeholder
location="classpath:esb-project-config.properties,
classpath:some-other-props-if-needed.properties"
order="0"/>
2. PropertyOverrideConfigurer
<context:property-override
location="classpath:esb-project-config.test.properties"/>
для переопределения определенных индивидуальных свойств. Некоторые примеры здесь
3. Системные переменные
Вы можете использовать префикс для управления свойствами, специфичными для среды, это можно сделать с помощью системных переменных:
<context:property-placeholder
location="${ENV_SYSTEM:dev}/esb-project-config.properties"/>
В этом случае он всегда будет выглядеть:
<context:property-placeholder
location="dev/esb-project-config.properties"/>
по умолчанию, если не установлена системная переменная ENV_SYSTEM
. Если он установлен на qa
, например, он будет автоматически выглядеть:
<context:property-placeholder
location="qa/esb-project-config.properties"/>
4. Spring Профили
Другой подход заключается в создании специфического профиля beans. Например:
<beans profile="dev">
<context:property-placeholder
location="esb-project-config.dev.properties"/>
</beans>
<beans profile="qa">
<context:property-placeholder
location="esb-project-config.qa.properties"/>
</beans>
Соответствующий esb-project-config
будет загружен в зависимости от набора профилей. Например, это загрузит esb-project-config.dev.properties
:
GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles( "dev" );
ctx.load( "classpath:/org/boom/bang/config/xml/*-config.xml" );
ctx.refresh();
- ПРИМЕЧАНИЕ. Подходы "Системные переменные" и "Профили системы" обычно используются для переключения между различными средами, а не только "dev < == > test" в режиме dev, но все же являются полезными функциями, которые необходимо знать.
Ответ 3
- В теге контекста вы можете указать, что если файл свойств
не существует, он не должен терпеть неудачу.
- Файлы свойств загружаются в том порядке, в котором они объявлены. (Эта
также может быть свойством объявлять тег. Не уверен)
- Если свойство объявлено несколько раз, последнее загруженное значение
используется.
Мы используем эти три функции следующим образом:
Мы объявляем два файла свойств:
classpath:esb-project-config.properties,
classpath:esb-project-config-override.properties
Первый файл свойств содержит разумные настройки по умолчанию и конфигурацию разработки. Этот файл является частью вашего приложения.
Второй файл свойств - это файл, доступный в тестовом классе или даже пути производственного класса сервера приложений. Этот файл внешний приложения
Таким образом, мы можем переопределить свойства для каждой среды и иметь только одну версию нашего приложения.
Итак, вот пример свойств, которые мы используем:
<context:property-placeholder
ignore-resource-not-found="true" ignore-unresolvable="true"
location="classpath:esb-project-config.properties,classpath:esb-project-config-override.properties" />
Ответ 4
Мой предпочтительный метод, добавленный spring 3.1, выглядит следующим образом:
В вашем * -context.xml:
<context:property-placeholder location="classpath:/web-${spring.profiles.active}.properties" />
и в web.xml:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>prod</param-value>
</context-param>
Затем вы можете указать среду во время выполнения, например:
mvn -Dspring.profiles.active=dev jetty:run
Или, однако, вы передаете аргументы в свой контейнер.
Ответ 5
Кажется:
<beans profile="dev">
<context:property-placeholder location="classpath:config/dev.properties"/>
</beans>
<beans profile="prod">
<context:property-placeholder location="classpath:config/prod.properties"/>
</beans>
Это не работает. Но вы можете сделать:
<context:property-placeholder location="classpath:config_${spring.profiles.active}.properties" />