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

Question

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

Опция получить их там тот путь во-первых с Resharper состояла бы в том, чтобы определить живой шаблон, подобный:

$uiElement$ = $dto$;
$dto$ = $uiElement$;

Это позволит Вам вводить их однажды, и это копирует его для Вас, и затем можно вырезать и вставить версию сохранения к другому методу.

60

java web-applications configuration design-patterns

задан Dónal Boyle 14 October 2009 в 21:02

8 ответов

This is heavily going to depend on what options the web application servers give you. We have multiple environments for JBoss with different JDBC URLs, the JNDI name remains the same across all servers, just the configuration on the local instance changes, so nothing goes wrong from build to build.

I guess the short answer is that the best practice is to externalize the configurations and keep a good file in place with the correct settings for each server, and have the web app read that configuration. The exact nature of the externalization and reading is going to depend on the specific configuration and application server.

EDIT: These configurations do not exist as part of the war (ear in our case) that way they are not overwritten.

6

ответ дан 24 November 2019 в 17:53

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

Также поможет простой тест, который проверяет, что все настроено правильно.

2

ответ дан 24 November 2019 в 17:53

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

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

31

ответ дан 24 November 2019 в 17:53

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

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

/config/fun_prog/config.xml

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

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

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

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

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

0

ответ дан 24 November 2019 в 17:53

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

В Seam сборка проекта выполняется с помощью файлов Ant. Каждый файл, содержимое которого может различаться, определяется для каждого профиля, например, источник данных, сценарии 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 build вызов из командной строки. Это короткий пример того, что делается в Seam done.

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

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

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

1

ответ дан 24 November 2019 в 17:53

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

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

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

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

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

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

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

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

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

Наличие конфигурации в базе данных

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

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

Дополнительные методы