Обработка файлов конфигурации в веб-приложениях Spring - PullRequest
Новая
       27

Обработка файлов конфигурации в веб-приложениях Spring

10 голосов
/ 11 мая 2011

Я несколько раз сталкивался с одной и той же проблемой, и мне хотелось бы узнать, что другие люди думают об этой проблеме: Предположим, у нас есть приложение Spring, упакованное как файл .war , и мы хотим запустить его в нескольких средах . (Разработка / тест / preprod / прод / и т.д.)

Для доступа к инфраструктуре, необходимой для приложения (базы данных / веб-сервисы и т. Д.), Мы храним информацию о доступе в файлах конфигурации, также в этих файлах находится некоторая бизнес-конфигурация. Допустим, мы используем .properties файлы для этой цели (потому что у нас есть весеннее приложение во время войны, и нам нравится, когда свойства читаются однострочными в appcontext) и также предположим, что в разных средах у нас нет одного и того же контейнера appserver / servlet. (например: dev, test: jetty, preprod: tomcat, prodd: glassfish)

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

Теперь недавно я столкнулся с вопросом от парня, выполняющего операции: «Итак, действительно ли мы должны генерировать новую сборку с соответствующим профилем на сервере сборки, если БД изменяется в среде preprod?» Я ответил: «Нет, вы можете перейти к ... / webapps / currentApp / WEB-INF / classes / config / application.properties и изменить там значения, а затем перезапустить контейнер"

Мы придумали решение, которое решает некоторые аспекты этой проблемы: используя плагин сборки Maven, мы встраиваем Jetty в войну, которая делает его пригодным для использования в качестве «исполняемой» войны, а также дает нам возможность иметь глобальную конфигурацию XML, из которого стартер встроенной Jetty создает / изменяет соответствующие файлы .properties в разобранном каталоге war и только затем запускает приложение.

Но, опять же, это не решает проблему, если вы хотите использовать что-то еще, кроме Jetty.

Как все сталкиваются с одинаковой ситуацией?

Ответы [ 3 ]

10 голосов
/ 11 мая 2011

Переменная среды, внешние конфигурационные файлы

У нас есть нечто похожее, веб-приложение, работающее в Tomcat / Weblogic с Spring.Мы определяем свойство среды CONFIG_PATH и помещаем все XML-файлы (включая конфигурацию Spring) и файлы свойств в этот каталог.

У нас есть несколько файлов свойств (для каждой среды), которые мы отправляемэто как файл tar.Веб-приложение загружает все файлы конфигурации Properties / Spring из каталога CONFIG_PATH.Эта переменная определяется как переменная среды в соответствующей среде

Таким образом, мы не затрагиваем файл WAR и не создаем отдельную WAR для среды.Подумайте об этом сценарии: файлы QA & PROD WAR созданы, файл QA протестирован QA, PROD WAR развернут в PROD, но что-то взрывается: (

Мы делаем что-то, как показано ниже:

В весенней конфигурацииxml, мы определяем: 

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="order" value="0"></property>
    <property name="locations">
        <list>
            <value>file:${CONFIG_PATH}/App.properties</value>
        </list>
    </property>
</bean>

Ссылка всех переменных как обычно в конфигурации весны.

В файле web.xml мы определяем конфигурацию весны следующим образом: 

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>file:${CONFIG_PATH}/**/spring-config.xml
    </param-value>
</context-param>

Команда QA / PROD развертывает тот же артефакт с соответствующими файлами окружения. Если что-то взрывается, мы знаем, что только испорченные свойства env. HTH

4 голосов
/ 11 мая 2011

База данных

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

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

JNDI

JNDI настройки остаются неизменными в зависимости от среды;эти изменения устанавливаются администратором сервера приложений один раз и не меняются.(См. Oracle Tutorial )

Я говорю о парах имя / значение для конфигурации самого приложения, а не JNDI.

2 голосов
/ 11 мая 2011

для источников данных;в контексте tomcat это обычный подход для создания записи ресурса JNDI и отделения ваших записей / конфигов ресурса от вашего приложения.Если база данных изменена, вы можете перенастроить свой ресурс JNDI в своем контейнере (Tomcat, Jetty и т. Д.) И перезапустить.Если у вас есть контейнерная ферма, перезапуск ваших экземпляров tomcat не вызовет проблем.Вы можете отключить их на балансировщике нагрузки и перезагрузить, активировать.Я думаю, что в Jetty есть контекстный файл, в который вы можете добавить ресурсы JNDI.Кроме того, существует множество профилей для свойств, которые зависят от различных контекстов.Вы можете выбрать свой профиль с параметром "-P" maven, и ваш проект будет построен с этими конфигами, например, для различных целевых контекстов, таких как live и test.

...