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

Question

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

Answer 1

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

• log4j и JDK - это библиотеки для ведения журналов
• Commons Logging и SLF4J - это фасады журналирования: вам все еще нужна реальная реализация журналирования (например,log4j)

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

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

• Logback
• log4j
• JDK logging (на мой взгляд, случай «не изобретен здесь»СОЛНЦЕ)

Answer 2

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

Log4j

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

JDK Logging

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

Запись в журнал Commons и SLF4j

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

Answer 3

Чаще всего вы увидите их слоистыми.

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

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

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)

Answer 4

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

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