Общие стратегии при определении бинов Spring для разных сред

Question

Каковы общие стратегии определения группы компонентов, которые по-разному используются в средах разработки и производства?

Допустим, у меня есть 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 или distributed.xml в зависимости от среды и возьмите компонент resourceSystem.

Существуют ли в Spring подходящие инструменты или рекомендации для настройки определений компонентов для различных сред?

Спасибо.

Answer 1

Вот что говорит справочная документация Spring о PropertyPlaceholderConfigurer

PropertyPlaceholderConfigurer не ищет свойства только в указанном вами файле свойств, , но также проверяет соответствиеСвойства системы Java , если не удается найти свойство, которое вы пытаетесь использовать.

Как вы можете видеть выше, вы можете настроить свойство системы Java

на компьютере разработчика

-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 во время выполнения .

Answer 2

Это то, что я использовал во многих своих проектах.Пусть все независимые от вашей среды bean-компоненты, скажем, 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».

Answer 3

Эта функция доступна на радаре SpringSource и предназначена для будущих выпусков.

См. здесь и здесь .