Мы строим трехуровневые корпоративные решения, которые обычно состоят из нескольких модулей webapp и ejbjar, которые все общаются с db и имеют несколько точек внешней интеграции.
Каждый модуль обычно нуждается в собственных конфигурациях, которые могут меняться в течение срока службы решения. Развертывание это становится кошмаром, потому что теперь у нас есть 18 файлов свойств, которые необходимо помнить, чтобы скопировать и настроить также настройку источников данных, очередей, требований к памяти и т.д.
Я надеюсь, но не оптимистично, что может быть лучший способ. Некоторые варианты, которые мы рассмотрели/использовали, каждый с плюсами и минусами:
При всем этом вам все равно необходимо сконфигурировать источники данных и очереди и т.д. контейнером: (
Пользователь - простая таблица базы данных (раздел, ключ, значение). Добавьте "Версия", если вам это нужно, и оберните все это в простой класс ConfigurationService с помощью методов типа getInt(String section, String key)
Не много работы, и он делает код приложения очень аккуратным, а настройка с настройкой очень проста.
JNDI. Затем найдите этот объект в своих приложениях, чтобы настроить их. Преимущества - вы можете использовать настраиваемый объект конфигурации вместо более общих Map или Properties.JMX для настройки необходимых вам приложений. Преимущества - вы можете привязывать объекты, которые необходимо настроить непосредственно к MBean Server, а затем использовать такие хорошо известные инструменты, как jconsole или visualvm, для настройки компонентов вашего приложения.Оба способа поддерживают динамическую реконфигурирование ваших приложений во время выполнения. Я бы предпочел использовать JMX.
Я прошел несколько циклов поиска способов сделать это. У меня до сих пор нет определенного ответа.
Последний цикл завершился процессом, основанным на файлах свойств. Идея заключалась в том, что каждый экземпляр сервера был настроен с единственным файлом свойств, который настроил все. Этот файл был прочитан сценариями запуска, для установки параметров памяти, сервером приложений и самим приложением.
Главное, однако, в том, что этот файл не управлялся напрямую. Скорее, это был продукт процесса сборки. У нас был ряд файлов для разных целей, хранился в управлении версиями и шаг сборки, который объединил соответствующие. Это позволяет вам учитывать общие черты, которые разделяются по различным осям.
Например, у нас были разработки, непрерывная интеграция, QA, UAT, промежуточная и производственная среды, каждая со своей собственной базой данных. Серверы в разных средах нуждались в разных настройках базы данных, но каждый сервер в данной среде использовал одни и те же настройки. Итак, было что-то вроде development -db.properties, qa-db.properties и т.д. В каждой среде у нас было несколько видов серверов: веб-серверы, серверы управления контентом, серверы пакетного процесса и т.д. У каждого были параметры JVM, размер кучи и т.д., Которые отличались от других типов серверов, но согласовывались между серверами через сред. Итак, у нас было что-то вроде web -jvm.properties, cms-jvm.properties, batch-jvm.properties и т.д. У нас также был способ получить переопределения для конкретных систем - production-cms-jvm.properties. У нас также были общие свойства, которые устанавливают общие свойства и разумные значения по умолчанию, которые могут быть переопределены там, где это необходимо.
Наш процесс сборки был на самом деле немного сложнее, чем просто выбор правильных опций из каждого набора; у нас был мастер файл для каждого сервера в каждой среде, который указывал, какие другие файлы включать. Мы разрешили файлам указывать другие файлы для включения, поэтому мы могли бы построить график импорта для максимального повторного использования.
Это оказалось довольно сложным. Слишком сложно, я думаю. Но это действительно сработало, и это сделало очень, очень легко сделать изменения, влияющие на многие серверы контролируемым образом. Мы даже объединили набор исходных файлов от разработки, а другой - от операций, содержащих конфиденциальную информацию. Это был очень гибкий подход.
Я знаю, что это уже ответили, и мой ответ не обязательно является общим, но здесь я беру вещи:
Обратите внимание: здесь я рассматриваю только свойства системы/ресурсов, а не настройки приложения. На мой взгляд, параметры приложения (такие как порог оплаты или другие настройки должны храниться в базе данных, чтобы система могла быть перенастроена без перезапуска службы или возникновения простоев путем повторного развертывания или перепрочтения файла свойств).
Для настроек, которые влияют на то, как разные части системы соединяются друг с другом (например, конечные точки веб-службы и т.д.), я бы использовал дерево JNDI.
Подключение к базе данных и подключение JMS затем будут настроены с помощью консоли Websphere и могут управляться администраторами Websphere. Они также могут быть созданы как скрипты JACL, которые могут быть добавлены в управление версиями, если это необходимо.
В дополнение к ресурсам JNDI для дополнительных свойств, таких как имена пользователей для вызовов веб-сервисов для бэкэнд и т.д., я бы использовал Websphere "Связи пространства имен". Эти привязки можно отредактировать с помощью консоли Websphere и получить доступ через JNDI с помощью имени "cell/persistent/mypassword".
Таким образом, я мог бы создать привязку "mypassword" (строка), а управление для нее относится к администратору Websphere (от глаз разработчика или других людей, которым не следует иметь доступ к производственным системам), в то время как один и тот же файл EAR могут использоваться на dev, test, preproduction и production (что предпочтительнее иметь разные файлы EAR для разных систем, так как вероятность других ползучих различий уменьшается).
Тогда код Java будет использовать простой поиск JNDI (и, возможно, кешировать значение в памяти).
Преимущества над файлами свойств:
Преимущества по свойствам базы данных:
Надеюсь, что поможет
Используйте несколько проектов maven и непрерывную интеграцию (например, hudson или jenkins), чтобы построить конфигурационную банку, которая включает в себя все свойство файлов для каждой среды (dev, qa, prod), а затем собрать все как EAR. Но тогда вещи не могут быть легко изменены в производстве при необходимости.
Я думаю, что config должен быть в базе данных экземпляра приложения. Ваша локальная конфигурация может отличаться от dev и QA, PROD, DR и т.д.
Что вам нужно, это простой способ получить конфигурацию базы данных простым способом.
Я создаю отдельный проект с предоставленной зависимостью от конфигурации Apache-конфигурации У него есть много способов хранения данных, но мне нравятся базы данных, а конфигурации живут в среде базы данных.
import javax.sql.DataSource;
import org.apache.commons.configuration.DatabaseConfiguration;
public class MYConfig extends DatabaseConfiguration {
public MYConfig(DataSource datasource) {
super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");
}
}
Поместите большинство настроек в БД и попробуйте простой экран для изменения Это. Внутри мы можем иметь общую конфигурационную службу EJB, которая может читать и изменять значения. Каждый модуль может иметь пользовательский расширенный версии с определенными геттерами и установщиком.
Конфигурации Commons как простой API, вы можете написать графический интерфейс по своему усмотрению. Вы можете сделать интерфейс в любом случае. Или как быстрая победа не имеет интерфейса.
Версия управляет всеми файлами свойств, а затем проверяет их на производство и проверить его в производственной ветке после внесения изменений.
Контроль версий велик. Добавьте еще одну конфигурацию DatabaseConfiguration, используя композицию. Класс, который вы расширяете, - это активная конфигурация, а составленная - это аудит. Существует другой конструктор, который может иметь версию. Просто перегрузите правильные методы, чтобы получить желаемый эффект.
import javax.sql.DataSource;
import org.apache.commons.configuration.DatabaseConfiguration;
public class MYConfig extends DatabaseConfiguration {
final DatabaseConfiguration audit;
public MYConfig(DataSource datasource) {
super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");
audit = new DatabaseConfiguration("TABLE_CONFIG_AUDIT", "PROP_KEY", "PROP_VALUE");
}
@Override
public void addProperty(String key, Object value) {
Object wasValue = super.getProperty(key);
super.addProperty(key, value);
audit.put(key,wasValue);//add version code
}
}
Интересный альтернативный формат файла конфигурации: напишите черту scala. Тогда ваш файл конфигурации может быть просто файлом scala, который вы компилируете и оцениваете при запуске сервера. http://robey.lag.net//2012/03/26/why-config.html