Я не могу себе представить, что мой вопрос настолько специфичен для моего случая, но я не видел подобных вопросов, заданных здесь до сих пор.
Я бы хотел иметь возможность указать файл log4g.properties вне моей упаковки .ear, чтобы было проще изменять уровни ведения журнала, не переупаковывая ухо. На самом деле, наиболее неотложной мотивацией для этого является уже установленное в нашей группе соглашение о том, чтобы файлы свойств log4j находились за пределами уха, поэтому обойти это ограничение (поместив файл log4j.properties в каталог APP-INF / classes или корень уха и т. д.) не применимо.
Ухо содержит EJB без состояния, который делегирует серии Spring POJO для выполнения своего поведения.
Я видел, как другие в моей группе развертывали файл WAR внутри EAR, и он нес единственную ответственность за загрузку файла свойств log4j по указанному (внешнему) пути с использованием прослушивателя контекста. Хотя путь является «внешним» для EAR, он все еще находится на пути к классам. Например, папка / config находится в пути к классам, а WAR использует прослушиватель контекста для загрузки log4j.properties из /config/appname/log4j.properties.
Для меня использование WAR, единственной целью которого является загрузка файла log4.properties, является хаком / излишним.
Должен быть лучший путь, верно?