log4j2 протоколирование кода в банке EJB на JBoss EAP 7

Question

Я делаю следующее: переносит несколько устаревших приложений из WebLogic в JBoss EAP 7. Некоторые из компонентов, портированных, являются EJB. Другие - сервлет-приложения, которые вызывают эти EJB. Эти EJB развернуты в ejb-jars. Я знаю, что я мог бы обернуть все это в большой файл EAR, но мы не хотим этого делать. Сервлеты и банки EJB должны быть отдельно развертываемыми компонентами.

Тогда есть настройка регистрации. Мы используем log4j2, и мы хотим сохранить независимость от настройки ведения журнала JBoss. Я создал модуль JBoss, который содержит все банки log4j2 с соответствующими зависимостями и работает журнал. Сервлет запускается и регистрируется, вызывает EJB, и они работают.

Единственная проблема заключается в том, как настроить ведение журнала EJB. В веб-приложении, таком как сервлет, просто, просто укажите файл конфигурации log4j в web.xml. Каков аналог для банка ejb? Я не мог придумать способ.

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

Каков правильный способ задания конфигурации log4j2 в EJB, развернутой в банке EJB на JBoss EAP7?

Answer 1

Я ранее размещал в этом пространстве решение, использующее методы @postConstruct и @preDestroy для инициализации и закрытия объектов LoggerContext.

Этот план развалился, когда я попытался распространить его на сессионные компоненты без состояния. Это работало хорошо для Stateful Beans. Или так я думал. В конце концов я нашел Oracle document on EJB Restrictions, который выявил слабые места в том, что я делал. Мое «решение» включало не конечный статический член LoggerContext класса EJB. Я нашел способ сделать его окончательным, что позволило работать без гражданства. Но я все больше недовольна своим подходом. Даже в случае с состоянием я обнаружил проблемы, которые могут укусить меня позже в кластерной среде.

То, что я теперь считаю, что я не должен делать то, что я пытаюсь сделать.

Я не могу даже представить себе сложность того, что будет выглядеть static final LoggerContext, если EJB был распространен на другой машине в кластере. Такие объекты, как LoggerContext, не входят в состав элементов, статических или не связанных с контейнерами, такими как EJB.

Даже не ясно, что EJB являются правильной технологией внедрения для того, что я пытаюсь построить. Мои варианты использования не являются транзакционными, поэтому реализация EJB не является сильной, поэтому один возможный путь полностью исключает EJB.

Настоящим сообщением является то, что если указаны EJB или другие компоненты, управляемые контейнером, вероятно, лучше всего использовать систему ведения журнала, предоставляемую контейнером. Мне нравится log4j2, но до тех пор, пока JBoss не поддержит его, лучше придерживаться предоставленного контейнером log4j1 или какой-либо другой структуры.