Как Log4j, commons-logging, JDK-Logging и SLF4J связаны друг с другом?

являются ли они альтернативами, зависимостями, API или реализациями друг друга? И почему они существуют?

4 ответов


Ах, фреймворки ведения журнала на Java. Ваш вопрос смешивает 2 разных типа библиотек:

  • log4j и JDK logging-это библиотеки для обработки ведения журнала
  • Викискладе лесозаготовки и SLF4J входе фасады: вы все еще нуждаетесь в практике лесозаготовок (как к log4j)

Если вы пишете библиотеку, которая будет использоваться в чужой системе, то вы должны использовать фасад ведения журнала, потому что вы не знаете, какую структуру ведения журнала они будут использовать. В в этом случае используйте SLF4J (ведение журнала Commons старше и имеет некоторые проблемы с загрузчиком классов).

Если вы контролируете все приложение и можете диктовать, какие рамки ведения журнала использовать, вы можете выбрать свои собственные предпочтения. Мои предпочтительные решения (в порядке предпочтения):

  • Logback так
  • настройки log4j
  • JDK logging (на мой взгляд, случай "не изобретен здесь" солнцем)

Я тоже недавно этим занимался. Я использую Log4J в течение многих лет с журналом Commons И недавно переключился на SLF4J.

настройки log4j

Log4j является основой для на самом деле выполнение записи/распространения журнала. Он чрезвычайно гибкий: вы можете направлять его для отправки сообщений журнала в файлы, системный журнал,удаленный мониторинг и т. д. Вы также можете настроить несколько регистраторов, категории журналов, включить контекст в записи и так далее. Это один из самые популярные системы ведения журнала.

ведение журнала JDK

встроенный журнал JDK (который я никогда не использовал, если честно) был добавлен в JDK 1.4.2. Из того, что я собрал, он не очень популярен, потому что он не такой гибкий, как Log4j, но я бы приветствовал комментарии :).

Ведение Журнала Commons и SLF4j

оба они являются фасадами поверх различных фреймворков ведения журнала, которые представляют общий интерфейс для вашего приложение. Например, вы можете использовать CL / SLF4J в своем приложении, и они автоматически обнаружат базовую реализацию регистратора (Log4J, JDK logging или встроенный регистратор, который просто делегирует System.err.println()). Преимущество заключается в том, что вы или ваш конечный пользователь можете решить переключить базовую реализацию ведения журнала по желанию, и они значительно упростят вашу реализацию, удалив многие сложности ведения журнала Log4J и JDK.


чаще всего вы увидите их надела.

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

типичная настройка-использовать SLF4J для входа в ваш код, а затем использовать log4j в качестве базового" выходного " слоя, используя соответствующий мост slf4j - >log4j (jar, который вы просто включаете в свой путь к классам). Чтобы объединить ведение журнала из разных источников, существуют различные мосты. Для например, многие серверы приложений (например, tomcat) будут использовать JDK-logging, чтобы избежать принуждения "нестандартной" структуры ведения журнала к развернутым приложениям. Для этой цели slf4j имеет мост, который будет принимать все выходные данные из JDK-logging. Итак, это может быть стек

JDK-logging <- Your app-server or framworks might log using this
  |
(JDK->Slf4j bridge)
  |
Slf4j <- your application logs using Slf4j
  |
(Slf4j->log4j bridge)
  |
log4j <- log4j is just responsible for outputting to the appenders you configure (file, console etc)

SLF4J - это универсальный API с разными бэк-эндами (любая другая система ведения журнала). Log4j и commons-logging (CL) различные библиотеки ведения журнала, CL является ископаемым. Но они все!--1-->есть фатальный недостаток, поэтому sun изобрели ведение журнала JDK.

Что касается меня, я предпочитаю SLF4J как самый гибкий и Logback так в качестве бэкэнда для него. Logback является самым современным и имеет много приятных функций.