Log4j 2 не пишет журналы в приложении Spring 2.5 Tomcat - PullRequest
Новая
       10

Log4j 2 не пишет журналы в приложении Spring 2.5 Tomcat

1 голос
/ 04 апреля 2019

Я вытащил старый проект, основанный на Spring 2.5 и Log4j 1.2, и начал обновлять его до современных библиотечных зависимостей.

Обновление Spring стоит времени, поэтому я начал с других библиотек и перешел с Log4j 1.2 на Log4j 2.

Я уже исправил все проблемы с зависимостями, используя плагин maven inspecer!

Мои зависимости maven теперь выглядят так: 

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-api</artifactId>
  <version>2.11.2</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.11.2</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-1.2-api</artifactId>
  <version>2.11.2</version>
</dependency>

В моем (старом) файле web.xml по-прежнему настроен следующий файл: 

<listener>
  <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>

<context-param>
  <param-name>log4jConfigLocation</param-name>
  <param-value>classpath:log4j.properties</param-value>
</context-param>

Поэтому я предположил, что все должно работать из-за обратной совместимости. Но в лог-файле моего кота появляется только следующее: 

04-Apr-2019 12:45:05.035 INFORMATION [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log Initializing log4j from [classpath:log4j.properties]
04-Apr-2019 12:45:05.068 INFORMATION [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
04-Apr-2019 12:45:17.661 INFORMATION [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'test'

и больше ничего ... где должны быть тысячи записей журнала ...

Я безуспешно искал все лог-файлы tomcat - нет никаких исключений и ничего другого, что подсказывает мне, почему мой код не будет работать с Log4j2 - какие-либо подсказки?

При возврате к log4j 1.2 все работает как положено.

Ответы [ 2 ]

1 голос
/ 05 апреля 2019

В конце все было довольно просто:

Я скопировал зависимости (api, core) из mvnrepository.com, чтобы они содержали: 

<scope>test</scope>

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

И последнее, но не менее важное: кажется, что конвертер log4j для свойств на самом деле не завершен, поэтому я параллельно добавил свойства log4j2.properties, чтобы получить результаты для rollAppender.

0 голосов
/ 04 апреля 2019

Пожалуйста, рассмотрите ответ как попытку устранения неполадок описанной ситуации.Ответ "общий", потому что здесь слишком много вещей может пойти не так, очень трудно сказать, не зная код и конфигурации, и отражает то, как я бы подошел к этой задаче

Миграция log4j 1.x в log4j2.x не так просто, как просто переключение банок.Итак, прежде всего, убедитесь, что вы понимаете (и применяете к своей базе кода) это руководство по миграции Некоторые импорты должны быть изменены.

Тогда я думаю, что вы должны убедиться, что log4j 1.xне распространяется на артефакт вашего приложения (одна из возможных причин состоит в том, что он определен как транзитивная зависимость)

Чтобы отследить это, запустите mvn dependency:tree, а если нет log4j 1.x jars -это хорошо.

Теперь, иногда (например, в случае самого Spring) библиотеки и, возможно, ваш собственный код не используют log4j-логгеры напрямую, а вместо этого используют slf4j.В этом случае вам понадобится привязка slf4j к log4j2: https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/

Затем вы можете начать проверку конфигурации.Лучший способ - это отладить ваше приложение, которое имеет что-то вроде где-то в коде: 

 logger.info("Some message");

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

...