Я работаю над проектом Java EE, файлы конфигурации которого были в папке resources
. Веб-проект собирается в военный файл с помощью Maven и развертывается в Tomcat.
Затем я начал выполнять некоторую поддержку и попытался перенести конфигурации, которые в какой-то степени были успешными.
На всякий случай Вам интересно, как это было на производстве до того, как я отредактировал код, вот оно:
// x stands for `application.conf` or `en.properties` depending on where in the code the file is being
getClass().getClassLoader().getResourceAsStream(x)
Я переместил каждый файл из resources
в /CATALINA_BASE/conf/myProject
, и я читаю по этим путям в код. (мне это не кажется хорошей практикой)
А вот моя версия:
// x stands for `application.conf` or `en.properties` depending on where in the code the file is being read
new File(System.getProperty("catalina.base") + "/conf/myProject/x")
Очевидно, это отлично работает, но в проекте также есть файл log4j2.properties
, который был автоматически читать из пути к классам раньше, и поскольку я вынес конфигурацию извне, я не могу ее прочитать.
Я пробовал устанавливать параметр внутри web.xml
, как показано ниже (не уверен, что это правильно to do)
<web-app>
...
<context-param>
<!-- also tried with log4jConfigLocation-->
<param-name>log4Configuration</param-name>
<param-value>file:${catalina.base}/conf/myProject/log42.properties</param-value>
</context-param>
...
</web-app>
Вывод ошибки при запуске приложения:
ERROR StatusLogger Файл конфигурации log4j2 не найден. Использование конфигурации по умолчанию: запись в консоль только ошибок. Задайте для системного свойства 'org. apache .logging.log4j.simplelog.StatusLogger.level' значение TRACE, чтобы отобразить ведение журнала внутренней инициализации Log4j2.
SLF4J: Не удалось загрузить класс «org. slf4j.impl.StaticLoggerBinder ".
SLF4J: По умолчанию реализация регистратора не работает (NOP)
Любые предложения приветствуются.
ОБНОВЛЕНИЕ: Tomcat, запущенный на сервере, обслуживает несколько других приложений, поэтому установка аргументов виртуальной машины не является вариантом для меня, поскольку другие проекты могут иметь свои конфигурации log4j в своем пути к классам, а аргументы виртуальной машины могут нарушить эти конфигурации.