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

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

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

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

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

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

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

Но существует ли устоявшаяся передовая практика?

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

Спасибо, Кертис.


configuration distribution jakarta-ee ear
person Curtis Patrick    schedule 21.09.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Isaac    schedule 06.10.2010
comment
Исаак, спасибо за ответ. Я рассмотрю использование записей среды. (Извините, недостаточно представителей, чтобы поставить большой палец вверх, я надеюсь, что кто-то другой сделает это от моего имени) - person Curtis Patrick; 12.10.2010

arrow_upward
0
arrow_downward

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

Вот более подробный ответ, который я написал давным-давно на java. net на аналогичный вопрос, но мы использовали Glassfish.

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

person ewernli    schedule 22.09.2010
comment
Спасибо, что подтвердили мои опасения. :) - person Curtis Patrick; 25.09.2010
comment
(извините, недостаточно очков репутации, чтобы утвердить ваш ответ) - person Curtis Patrick; 25.09.2010