Какова наилучшая практика для сохранения параметров конфигурации в файлах EAR?

Question

Мое приложение развернуто в виде файла EAR.

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

Это было легко с Oracle 10G OAS, так как EAR был разложен в каталог, что обеспечило легкий доступ к файлам конфигурации.

При использовании 11G EAR не взрываются, что приводит к дополнительной документации по взрыву, модификации и рекомбинации EAR.

Мне кажется, что это должно быть относительно распространенная проблема с решением, возможно, стандартным через J2EE, что я просто не сталкивался или не признал его как решение, которое искал.

Некоторые альтернативы включают в себя: 1) Предоставление утилиты, которая будет изменять файл EAR перед развертыванием. 2) Храните все параметры конфигурации в отдельном месте. 3) Сохраните все настройки конфигурации в базе данных; доступ к базе данных через контейнер обеспечивает соединение через JNDI.

Но есть ли признанная лучшая практика?

В отсутствие этого, какой подход сработал для вас?

Спасибо Curtis

Answer 1

Я проделал значительную работу по этому вопросу с одним из моих клиентов.В двух словах (что, я считаю, должно вам помочь):

Если вы должны использовать файлы конфигурации , размещение файлов конфигурации внутри EAR (посредством разнесения / переупаковки) имеет недостаток:файлы EAR не переносимы между различными средами (например, средами QA и производственными средами).Со временем это увеличивает накладные расходы, и всегда есть странная вероятность путаницы между средами.Такой подход применим только для элементов конфигурации, которые не зависят от среды , то есть остаются одинаковыми во всех средах SDLC (QA, тестирование и т. Д.).

В качестве альтернативы вы можете поместить эти файлы вотдельный каталог и добавьте этот каталог в classpath вашего сервера.Это делается по-разному на каждом сервере приложений;в WebSphere это делается с помощью средства «разделяемых библиотек».

Подход, который нам лучше сработал в долгосрочной перспективе, состоит в том, чтобы использовать то, что технология J2EE фактически предназначена для таких задач - с использованием resource environment entries, доступный через стандартный механизм JNDI в пространстве имен java:comp/env.

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

Answer 2

Насколько я знаю, это все еще одна из болевых точек, и ваш анализ в основном правильный.

Вот более подробный ответ Я давно писал на форуме java.net на похожий вопрос, но мы использовали Glassfish.

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