Должны ли новые проекты использовать logback вместо log4j?

Ответ 1

Вы должны использовать SLF4J + Logback для ведения журнала.

Он предоставляет опрятные функции, такие как параметризованные сообщения и (в отличие от общедоступных записей) контекстный диагностический контекст (MDC, javadoc, документация).

Использование SLF4J делает бэкэндинг регистрации более удобным.

Кроме того, SLF4J поддерживает привязку других фреймворков регистрации к реальной реализации SLF4J, которую вы будете использовать, так что события регистрации из стороннего программного обеспечения покажут в ваших унифицированных журналах - за исключением java.util.logging, которые не могут соединяться так же, как и другие фреймворки ведения журнала.

Bridging jul объясняется в javadocs для SLF4JBridgeHandler.

У меня был очень хороший опыт использования комбинации SLF4J + Logback в нескольких проектах, и разработка LOG4J в значительной степени зашла в тупик.

SLF4J имеет следующие остальные недостатки:

• Он не поддерживает varargs, чтобы оставаться совместимым с Java < 1.5
• Он не поддерживает одновременное использование как параметризованного сообщения, так и исключения.
• Он не содержит поддержки вложенного диагностического контекста (NDC, javadoc), который имеет LOG4J.

Ответ 2

У автора (как Logback, так и Log4j) есть список причин для изменения на http://logback.qos.ch/reasonsToSwitch.html.

Вот некоторые из них, которые торчали у меня;

• Быстрая реализация

  Основываясь на нашей предыдущей работе над log4j, Внутренние элементы журнала переписано, чтобы выполнить около десяти раз быстрее при определенном критическом исполнении пути. Не только журнал компонентов быстрее, они имеют меньший объем памяти.

• Автоматическая перезагрузка конфигурации файлы

  Logback-classic может автоматически перезагрузите файл конфигурации модификация. Процесс сканирования как быстро, так и безопасно, поскольку это не предусматривают создание отдельного нить для сканирования. Этот технический тонкость гарантирует, что воспроизведение хорошо в пределах серверов приложений и более широко в рамках JEE окружающая среда.

• Трассировка стека с данными упаковки

  Когда logback печатает исключение, трассировка стека будет включать упаковку данные. Вот пример трассировки стека созданный с помощью logback-demo веб-приложения.

  14: 28: 48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 является не действительное значение java.lang.Exception: 99 неверно
  в ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/: na] at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar: 1.2.9] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [Сервлет-апи-2.5-6.1.12.jar: 6.1.12]
  в org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar: 6.1.12] в ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/: na] at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar: 6.1.12] в org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar: 6.1.12] в org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar: 6.1.12] в org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [Причал-6.1.12.jar: 6.1.12]

  Из вышесказанного вы можете узнать что приложение использует Struts версии 1.2.9 и был причал версии 6.1.12. Таким образом, стек трассы быстро сообщают читателю о классах, исключение, но также пакет и которые они принадлежат. когда ваши клиенты отправляют вам стек trace, как разработчик вы не будете дольше нужно попросить их отправить вас информация о версиях которые они используют. информация будет частью стека след. См. Преобразование "% xThrowable" слово для деталей.

  Эта функция может быть весьма полезна для что некоторые пользователи ошибочно считают его особенностью их IDE.

• Автоматическое удаление старых архивов журналов

  Установив свойство maxHistory TimeBasedRollingPolicy или SizeAndTimeBasedFNATP, вы можете контролировать максимальное количество архивные файлы. Если ваш прокат политика требует ежемесячного опрокидывания и вы хотите сохранить один год журналы, просто установите maxHistory свойство 12. Архивированные файлы журналов старше 12 месяцев автоматически удаляется.

Там может быть предубеждение, но тот же парень написал оба фреймворка, и если он говорит использовать Logback over Log4j, он, вероятно, стоит его слушать.

Ответ 3

Я бы использовал slf4j для регистрации во всех случаях. Это позволяет вам выбрать, какой фактический бэкэнд вы хотите использовать, во время развертывания вместо времени кода.

Это оказалось для меня очень ценным. Это позволяет мне использовать log4j в старых JVM и logback в 1.5+ JVM, а также java.util.logging при необходимости.

Ответ 4

Отслеживать больше знаний Java EE:
в целом (от кода к документации) с учетом контейнеров - как сосуществуют несколько приложений, как реализованы загрузчики классов и т.д. Контексты для регистраторов, JNDI, JMX-конфигурации включены и т.д.

от перспективных разработчиков почти так же, Logback добавляет Параметрированное ведение журнала (не нужно использовать if (logger.isDebugEnabled()), чтобы избежать сбоев в конкатенации строк)

Log4j - только гигантский плюс - это старая поддержка JVM, небольшая (IMO) NDC (только для журнала MDC), некоторые расширения. Например, я написал расширение для configureAndWatch для Log4j, нет такой вещи для журнала

Ответ 5

оригинальный log4j и logback были разработаны и реализованы одним и тем же парнем.

несколько инструментов с открытым исходным кодом использовали SLF4J. Я не вижу существенных недостатков в этом инструменте. Поэтому, если у вас нет много расширений для log4j в вашей кодовой базе, я бы продолжил логин.

Ответ 6

Я бы подумал, что ваше решение должно совпадать с тем, что было бы, если бы вы решали между использованием log4j или Jakarta Commons Logging - разрабатываете ли вы библиотеку, которая будет включена в другие приложения? Если это так, то не кажется справедливым заставить пользователей вашей библиотеки также использовать выбранную вами библиотеку журналов.

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

Ответ 7

Я не знаком с SLF4J, и я только кратко посмотрел на журнал, но приходят на ум две вещи.

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

Во-вторых, я думаю, что в некоторых проектах один инструмент лучше другого инструмента, а наоборот может быть правдой в другом проекте. Я не думаю, что один инструмент всегда лучше, чем другой инструмент. В конце концов, нет серебряной пули.

Чтобы ответить на ваш вопрос - да и нет. Это зависит от проекта и насколько знакомы команды с одним инструментом. Я бы не сказал "не используйте log4j", если вся команда очень им удобна, она удовлетворяет всем потребностям, а logback не предлагает ничего, что нам нужно для выполнения задачи.