Проблемы с заменой Log4j на LogBack, недостатки log4j-over-slf4j.jar

Question

Итак, я портировал некоторые из наших сервисов на использование Logback поверх log4j, и я использовал jar log4j-over-slf4j, чтобы подделать log4j для наших унаследованных зависимостей.Единственная проблема заключается в том, что log4j-over-slf4j не реализует многие классы log4j, поэтому я вижу несколько достойных классов, не нашедших исключений из зависимых jar-файлов.Как люди обошли это?Достаточно ли просто поместить nlog4j в ваш путь к классу вместо файла log4j-over-slf4j?Я еще не проверил эту последнюю идею, но планирую завтра.

Ссылка:

• http://www.slf4j.org/legacy.html
• http://www.slf4j.org/nlog4j/

Answer 1

Единственная проблема заключается в том, что log4j-over-slf4j не реализует многие классы log4j, поэтому я вижу несколько достойных классов, которые не нашли исключений из зависимых jar-файлов. Как люди обошли это?

Ну, я полагаю, вы столкнулись с "проблемами", явно упомянутыми в устаревших API-интерфейсах , которые вы разместили:

Когда это не работает?

Модуль log4j-over-slf4j не будет работать, когда приложение вызывает log4j компоненты, которых нет в мост. Например, когда приложение код напрямую ссылается на log4j дополнения, фильтры или PropertyConfigurator, затем log4j-over-slf4j будет недостаточная замена для log4j. Тем не менее, когда log4j настроен через файл конфигурации, будь то log4j.properties или log4j.xml, Модуль log4j-over-slf4j должен просто отлично работает.

Если зависимые файлы JAR находятся под вашим контролем, вам действительно следует попытаться перенести код с помощью инструмента SLF4J Migrator .

Достаточно ли просто поместить nlog4j в путь к классам вместо файла log4j-over-slf4j?

Это может решить ClassNotFoundException, но мне интересно, как будет работать вся регистрация. И учитывая, что NLog4J больше не разрабатывается активно, мне интересно, является ли это хорошим долгосрочным решением.