Шаблоны Конфигурации Веб-Приложений Java

Я удивлен, что никто не процитировал Jakarta Commons Configuration API (http://commons.apache.org/configuration/), чтобы ответить на этот вопрос. Это позволяет вам иметь иерархию файлов (или других источников конфигурации, таких как XML, JNDI, JDBC и т. д.). Это то, о чем говорил Джереми Сеги, и это дает вам хороший способ иметь как значения по умолчанию, так и локальные переопределения.

лучшая часть заключается в том, что это проверенное рабочее решение, так что вам не придется идти ремесло что-нибудь для себя.

вот некоторые возможные практики, которые я использовал или встречал. Объединение их обычно необходимо на практике.

подстановка значений переменных в conffiles при построении

вот пример того, как это можно сделать с помощью Apache Ant. Свойства Ant (${var.name}) можно управлять с помощью файлов конфигурации сборки:

<filterset id="variables.to.replace">
    <filter token="APPNAME" value="${app.name}"/>
    <filter token="WEBAPP-PATH" value="${webapp.path}"/>
    <filter token="ENCRYPT-ALGORITHM" value="${encrypt.algorithm}"/>
    <filter token="ERROR-MAILTO" value="${error.mailTo}"/>
    <!--...-->
</filterset>

<!-- Then, when building & copying the conf, replace the variables: -->
<copy todir="${properties.target.dir}">
    <!-- env specific conf files -->
    <fileset dir="${basedir}/env/${run.env}/webapp/WEB-INF/classes" />
    <filterset refid="variables.to.replace"/>
</copy>

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

подстановка переменных из conf inside war при запуске webapp

это то, что я обычно делаю при использовании Spring Framework, даже если есть только одна возможная конфигурация, получая преимущества разделения проблем. С помощью Spring вы можете заменить значения conf на PlaceholderPropertyConfigurer внутри контекста Spring при запуске webapp. В этом случае вам все равно нужно выбрать правильную конфигурацию, которую можно настроить, например, во время сборки.

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

чтение локального conf из предопределенного файла

этот подход, вероятно, самый простой в настройке: просто изобрести путь к файлу конфигурации, например,$HOME/mywebapp/conf.properties и сделать ваш веб-приложение каким-то образом прочитать его при запуске.

хорошие дело в том, что вам не нужно заботиться о conf при создании/развертывании веб-приложения. В любом случае, у вас должны быть некоторые разумные значения по умолчанию conf, которые затем могут быть переопределены локальным conf.

наличие conf в базе данных

Это наиболее гибкое решение для переопределения параметров conf, но также может усложниться в некоторых случаях. Имея конф в таблице с name и value колонки должны работать в большинстве случаев.

Of конечно, вы не можете настроить URL-адреса подключения JDBC в таблице базы данных, но это хорошее решение для простого текстового/числового conf, которое влияет на работу веб-приложения после настройки подключения к БД. Чтобы избежать снижения производительности, убедитесь, что вы каким-то образом кэшируете конф, если он будет часто доступен.

дополнительные практики

как указал kgiannakakis, это также помогает настроить страницу диагностики конфигурации какого-либо для вашего приложение.

Это в значительной степени будет зависеть от того, какие параметры дают вам серверы веб-приложений. У нас есть несколько сред для JBoss с разными URL-адресами JDBC, имя JNDI остается одинаковым на всех серверах, только конфигурация на локальном экземпляре изменяется, поэтому ничего не идет не так от сборки к сборке.

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

EDIT: эти конфигурации не существуют как часть войны (ear в нашем случае), поэтому они не перезаписываются.

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

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

хороший пример, что вы хотите используется в пласта или граали (заимствованные из рельсов). Есть профили, по умолчанию три: prod, dev, test, но вы можете определить больше, если хотите.

в проекте Seam сборка выполняется с помощью файлов Ant. Файл Eeach, содержимое которого может изменяться, определяется для каждого профиля, например источника данных, скриптов sql или файлов свойств.

import-dev.sql
import-prod.sql
import-test.sql

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

Ниже приведен фрагмент кода, который вы можете разместить в своем мишени!--6-->

<copy tofile="${war.dir}/WEB-INF/classes/import.sql" 
      file="${basedir}/resources/import-${profile}.sql"/>

JDBC url, имена драйверов могут быть экстернализованы в файлы свойств (конечно, с именами профилей в качестве суффиксов)

<filterset id="persistence">
     <filter token="transactionManagerLookupClass" value="${transactionManagerLookupClass}"/>

<copy tofile="${war.dir}/WEB-INF/classes/META-INF/persistence.xml" 
     file="${basedir}/resources/META-INF/persistence-${profile}.xml">
     <filterset refid="persistence"/>
</copy>

или значения свойств, которые вы можете передать вызову Ant build из командной строки. Это короткий пример того, что делается в шве.

другой вариант-использовать Maven. В maven способом это делается по свойствам и на профили, но вы можете использовать также отдельные модули для разделения конфигурации и создания других модулей с основной функциональностью. Типичные примеры использования свойств и профилей maven-это конфигурация запуска для нескольких баз данных, серверов развертывания и т. д. Это еще сложнее, когда вы хотите создать конфигурацию для разных поставщиков, но для Maven это не проблема:)

отличный пример использования профилей maven - это форма сообщения Карлос Санчез блог.

подводя итог, я настоятельно рекомендую посмотреть Ant / Seam параметризацию Maven (профили). Эти решения имеют еще одно преимущество: сценарий ant или maven можно запускать на сервере CI (например,Хадсон) и пусть запустить/проверить одновременно все ваши профили.

вы можете использовать шаблон конфигурации компонента на выбранном языке

это описано в книгах POSA (я думаю, что в 4-м томе)

(в Java вы можете использовать commons-конфигурация компонент ).

есть несколько возможных способов подойти к этому:

• используйте файлы свойств, как вы это делаете, но добавьте файл "meta properties", который используется для выбора файла свойств, используемого путем определения карты между значением среды (например, localhost hostname) на имя файла свойств для загрузки.

• поместите свои свойства в базу данных и определите соединение базы данных с таблицами свойств на сервере приложений как ресурс, который является подобран вашим веб-приложением.

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

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

Я уверен, что много вариантов на них и ваш подход возможны, что лучший выбор зависит от вашей ситуации.

что мы делаем работает довольно хорошо.

при запуске наши программы читают файл конфигурации в жестко закодированном пути. Скажем так:

/config/fun_prog/config.xml

каждая программа имеет другой жестко закодированный путь (Funprog находится в fun_prog, Super Server находится в sup_serv, что угодно), поэтому нам не нужно беспокоиться о том, что они ходят друг над другом.

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

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

Это не фантазии, но это работает очень хорошо. Это очень просто чтобы понять, добавьте новые параметры конфигурации, резервное копирование и редактирование. Работает на всех платформах (unix очевиден, Windows переводит пути, начинающиеся с / в c:\, поэтому он работает и без правок).

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

пожалуйста, взгляните на этот URL:http://issues.apache.org/jira/browse/CONFIGURATION-394

структура конфигурации, которую мы ищем, это что-то поверх конфигурации Apache Commons и должна поддерживать проблемы параллелизма, проблемы JMX и большинство магазинов(например.файл свойств. ,xml-файлы или PreferencesAPI).

то, что команда weblogic предоставляет на "консоли администрирования", представляет интерес, который через него вы можете иметь транзакционный(атомарный) обновления на конфигурациях так, чтобы зарегистрированные слушатели были уведомлены.

ребята из Apache настаивают на том, что этот проект выходит за рамки конфигурации Commons, возможно!

я прикрепил простую структуру конфигурации, посмотрите, пожалуйста.