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

Question

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

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

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

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

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

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

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

Как все справляются с та же ситуация?

726 3

spring war configuration architecture

3 ответов:

Comments

Ничего не найдено.

Rajendra · Accepted Answer · 2017-05-26 22:54:41

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

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

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

Таким образом, мы не касаемся файла войны и не строим отдельную войну для окружающей среды. Думаю, что этот сценарий: построенный ОК & прод War-файлы-ОК файл проверен ОК войны, прод война развернута в прод, но что-то взрывается :(

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

В spring config 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>
Ссылайтесь на все переменные, как обычно в spring config.

В сети.xml мы определяем spring config как ниже:
<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

duffymo · Accepted Answer · 2017-05-26 22:46:47

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

JNDI

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

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

Erhan Bagdemir · Accepted Answer · 2011-05-11 19:24:19

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