Как я могу сохранить Java параметры конфигурации EE за пределами EAR или ВОЙНЫ?

Я использую переменную среды, чтобы указать URL-адрес (который, вероятно, является URL-адресом file: //), в котором содержится моя конфигурация. Это очень просто настроить и не требует инфраструктуры JNDI.

Вот пример кода (набранный из памяти - я не компилировал / не тестировал это):

public void loadConfiguration() {
   String configUrlStr = System.getenv("CONFIG_URL"); // You'd want to use a more
                                                      // Specific variable name.
   if(configUrlStr == null || configUrlStr.equals("") {
       // You would probably want better exception handling, too.
       throw new RuntimeException("CONFIG_URL is not set in the environment."); 
   }


   try {
       URI uri = new URI(configUrlStr);
       File configFile = new File(uri);
       if(!configFile.exists()) {
          throw new RuntimeException("CONFIG_URL points to non-existant file");
       }
       if(!configFile.canRead()) {
          throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
       }
       this.readConfiguration(configFile);
   } catch (URISyntaxException e) {
       throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
   }



}

вы можете просто сохранить, тогда это обычный файл свойств java, который находится на пути к классу, и просто загрузить свойства?

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

Мои любимые места: Переменные среды и файлы свойств (как предложено Джаредом и Кгианнакакисом выше).

Таблица базы данных, хранящая свойства среды

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

Если ваше приложение использует базу данных

• , это относительно легко настроить
• Дает действительно простой способ управления / изменения значений
• Его можно хорошо интегрировать в процесс, сделав его частью скриптов БД

У нас были похожие требования к конфигурации при развертывании веб-приложения для разных разработчиков и на Amazon EC2: как отделить конфигурацию от двоичного кода? По моему опыту, JNDI слишком сложен и слишком сильно различается в зависимости от используемого контейнера. Кроме того, ручное редактирование XML очень подвержено синтаксическим ошибкам, поэтому от этой идеи отказались. Мы решили эту проблему с помощью дизайна, основанного на нескольких правилах:

1) должны использоваться только простые записи name = value

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

3) наш двоичный файл WAR должен быть реконфигурируемым без переупаковки

4) конфиденциальные параметры (пароли) никогда не будут упакованы в двоичный файл

Использование файлов .properties для всей конфигурации и использование System.getProperty ("домен"); , чтобы загрузить соответствующие файлы свойств, мы смогли выполнить требования. Однако системное свойство не указывает на URL-адрес файла, вместо этого мы создали концепцию, которую мы называем «домен», чтобы указать используемую конфигурацию. Расположение конфигурации всегда:
$ HOME / appName / config / $ DOMAIN.properties .

Поэтому, если я хочу запустить свое приложение, используя мою собственную конфигурацию, я запускаю приложение, устанавливая домен на мое имя:
-Ddomain = jason
при запуске, и приложение загружает файл:
/home/jason/appName/config/jason.properties
Это позволяет разработчикам делиться конфигурациями, чтобы мы могли воссоздать то же состояние приложения для тестирования и развертывания без перекомпиляции или переупаковки. Затем значение домена используется для загрузки .properties из стандартного расположения вне связанного WAR. который будет загружать:
/home/jason/appName/config/ec2.properties

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