Общие стратегии при определении bean-компонентов Spring для различных сред
Каковы общие стратегии определения группы компонентов, которые по-разному используются в средах разработки и производства?
Скажем, у меня есть 2 компонента, каждый из которых реализует один и тот же интерфейс. Один бин служит абстракцией для локальной файловой системы, другой подключается к распределенной файловой системе. Чтобы поддерживать развитие как можно более устойчивым, среда разработки должна использовать локальную реализацию файловой системы, в производственном выпуске используется компонент распределенной файловой системы.
В настоящее время то, что я ' у меня есть два определения xml.
native.xml
<bean id="resourceSystem" class="com.cust.NativeResourceSystem" />
distrib.xml
<bean id="resourceSystem" class="com.cust.HadoopResourceSystem">
<constructor-arg name="fs" ref="hdfs" />
</bean>
При создании контекста приложения я опускаю native.xml или distrib.xml в зависимости от в среде и захватите bean-компонент resourceSystem .
Существуют ли в Spring подходящие инструменты или передовые практики для настройки определений bean-компонентов для различных сред?
Спасибо.
3 ответа
Вот что говорится в справочной документации Spring о PropertyPlaceholderConfigurer
PropertyPlaceholderConfigurer не ищет свойства только в Свойствах файл, который вы указываете, , но также проверяет свойства системы Java , если не может найти свойство, которое вы пытаетесь использовать.
Как вы можете видеть выше, вы можете настроить свойство Java System
На машине разработки
-Dprofile=development
На производственной машине
-Dprofile=production
Таким образом, вы можете определить глобальные настройки контекста приложения, которые импортируют следующие настройки многоуровневого контекста
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<context:property-placeholder/>
<import resource="service-${profile}.xml"/>
<import resource="persistence-${profile}.xml"/>
<import resource="security-${profile}.xml"/>
</beans>
Имейте в виду, что все пути к расположению относятся к файлу определения, выполняющему импорт
Таким образом, этот тип конфигурации поддерживается Spring
. Обычно предпочтительнее сохранять косвенное указание на такие абсолютные местоположения, например, через заполнители «$ {...}» , которые разрешаются в отношении свойств системы JVM во время выполнения .
Эта функциональность находится на радаре SpringSource и запланирована для будущих релизов.
Это то, что я использовал во многих своих проектах.Все компоненты, независимые от среды, должны быть в файле common.xml, а все остальные - в dev.xml / qa.xml / prod.xml . Если вы используете ant для сборки своего проекта, то укажите среду в качестве аргумента для процесса сборки и позвольте сценарию сборки включать соответствующий env.xml и опускать другие. Я имею в виду, что сценарий сборки скопирует dev.xml как env.xml, если это среда разработки, или qa.xml как env.xml, если его QA. Таким образом, код, загружающий определения bean-компонентов, всегда будет использовать «common.xml, env.xml».