Внедрение зависимостей: как поддерживать несколько конфигураций?

Question

Предположим, мы создали систему с DI-фреймворком, которая работает довольно хорошо. Эта система в настоящее время использует JMS для «общения» с другими системами, которые не поддерживаются нами. Большинству наших клиентов нравится подход JMS и он используется в соответствии с нашей спецификацией. Компонент, который выполняет всю передачу сообщений, внедряется с помощью Spring в остальную часть приложения.

Теперь мы получили случай, когда один клиент не может внедрить решение JMS и хочет использовать другую технологию обмена сообщениями. Это не проблема, потому что мы можем просто внедрить службу обмена сообщениями, используя эту технологию, и внедрить ее в остальную часть приложения.

Но как мы должны управлять развертыванием и обслуживанием конфигурации? Поскольку приложение использует Spring, я мог бы представить, чтобы проверить все имеющиеся у меня конфигурации для этого приложения, и системный администратор может запустить приложение и передать имя файла DI XML, чтобы указать, какую конфигурацию следует загрузить. Но ... это просто не правильно. Существуют ли решения для таких случаев? Какие лучшие практики вы используете? Я мог бы даже представить более сложные сценарии, которые не содержат только одну замену службы ...

Большое спасибо!

Answer 1

Еще одно предложение: как насчет разделения вашей весенней конфигурации на две части: общий файл, который отправляется всем, и файл, специфичный для развертывания, который содержит определения различных бинов. Таким образом, вы могли бы иметь:

applicationCommon.xml
deploymentJMS.xml
deploymentOtherMessaging.xml
deploymentDifferentAgainMessaging.xml

Затем, когда ваши системные администраторы развертывают, они выбирают один файлов развертывания ???. Xml, в зависимости от сценария, и помещают его в каталог конфигурации

Ваше приложение будет настроено на использование подстановочного выражения для загрузки файла applicationCommon.xml и любого другого xml-файла в каталоге config, используя их вместе для построения контекста приложения (без особой заботы о том, какими именно файлами они были).

Различные XML-файлы развертывания будут жить в системе контроля версий, и администраторам sys не понадобятся никакие подробные знания, кроме знания того, что они всегда развертывают именованный файл XML-развертывания ???., Соответствующий сценарию.

(Если это веб-приложение, может потребоваться, чтобы каталог «config» был отделен от самого веб-приложения, чтобы повторное развертывание приложения не переписывало конфигурацию, специфичную для развертывания)

И, конечно, все это развертывание можно было записать в сценарий, чтобы правильный параметр был выбран параметром командной строки, например ...

Answer 2

Одним из решений является использование PropertyOverrideConfigurer в вашей конфигурации Spring. Это позволяет вам предоставить отдельный файл свойств, который может переопределять значения в конфигурации Spring при запуске контекста приложения. Таким образом, у вас есть стандартная конфигурация в вашем applicationContext.xml (которую вы отправляете всем) и дополнительный файл свойств, который позволяет настраивать конфигурацию для каждого развертывания без изменения основного файла конфигурации.

<bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
  <property name="location"><value>file:${config.dir}/config.properties</value></property>   
</bean>

Answer 3

У нас точно такой же вариант использования для одного из наших продуктов.

Мы создали разные наборы файлов applicationContext для каждого набора конфигураций. Наши контекстные файлы уже разделены на четыре разных файла (-servlet.xml, -services.xml, -dao.xml и т. Д.), И каждый файл в одном и том же «наборе конфигурации» имеет одинаковый префикс в своем имени файла.

В этом продукте мы используем Ant для создания файлов развертывания (.war). Мы настроили наш build.xml, чтобы мы могли передать другой параметр в скрипт сборки, чтобы контролировать, какой префикс используется при упаковке файлов. Например, мы запускаем

ant dist -DtargetApp=app1

, чтобы иметь файл развертывания, собранный из app1-dao.xml, app1-services.xml и т. Д., Упакованный.

Внутри Ant у нас есть логика, которая выглядит примерно так, чтобы установить свойство, используемое для имени "комплекта конфигурации":

<target name="set-environment">
    <!-- If the targetApp property is not set, default to "app1" -->
    <condition property="targetApp" value="app1">
        <not>
            <isset property="targetApp"/>
        </not>
    </condition>
    <echo>Using targetApp: ${targetApp}</echo>
<target>

Поскольку этот продукт является веб-приложением, значение свойства ${targetApp} затем используется для фильтрации значения в файле web.xml, чтобы сообщить Spring, какие файлы контекста приложения следует загрузить.

Answer 4

Я думаю, у вас есть выбор: отправлять разные версии продукта или использовать один продукт, который поддерживает обе системы обмена сообщениями.

Я бы предпочел один продукт. Если вы не хотите, чтобы администратор клиентов устанавливал параметр, определяющий систему обмена сообщениями, вы можете предоставить файл конфигурации для конкретного клиента или добавить эту информацию в файл лицензии (если есть), чтобы убедиться, что клиент использует правильная версия.

Только если системы обмена сообщениями зависят от несвободных сторонних библиотек, тогда я буду создавать разные продукты, просто чтобы избежать проблем с лицензией.