Шаблоны конфигурации веб-приложений Java

Ответ 1

В последнее время я чаще работаю с .NET, поэтому моя Java довольно ржавая. Я уверен, что это будет работать на любом языке с небольшой настройкой.

Мы используем расширение системы конфигурации .NET, которое позволяет нам использовать настройки среды и/или приложения в сочетании с более глобальной конфигурацией. Система конфигурации использует глобальную настройку для каждой машины, которая идентифицирует ее как dev, beta или production (по умолчанию). Набор файлов, загруженных по порядку, а параметр из последнего файла переопределяет любые параметры, определенные в ранее загруженном файле. Файлы загружаются в следующем порядке:

• Глобальные настройки
• Параметры, специфичные для приложения
• переопределяет среду приложения.

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

Ответ 2

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

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

Ответ 3

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

Подставляя значения переменных в 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 внутри войны при запуске webapp

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

В сборке проекта Seam выполняется файл Ant. Файл Eeach, содержимое которого может меняться, определяется для каждого профиля, например. datasource, sql-скрипты или файлы свойств.

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

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

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

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

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

<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 вызов сборки из командной строки. Это короткий пример того, что сделано в Seam.

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

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

Подводя итог, я настоятельно рекомендую искать Ant/Seam an Maven parametrization (профили). У этих решений есть еще одно преимущество: Ant или maven script могут выполняться на CI-сервере (например, Hudson) и запускать/одновременно проверяйте все ваши профили.

Ответ 7

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

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

(в java вы можете использовать компонент commons-configuration).

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

/config/fun_prog/config.xml

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

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

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

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

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

Ответ 10

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

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

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

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

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