log4j vs logback

Logback изначально реализует SLF4J API. Это означает, что если вы используете логбэк, вы фактически используете SLF4J API. Теоретически вы можете использовать внутреннюю часть API логбэка напрямую для регистрации, но это крайне не рекомендуется. Вся документация по логбэку и примеры для логгеров написаны с использованием SLF4J API.

Таким образом, используя logback, вы фактически будете использовать SLF4J, и если по какой-либо причине вы захотите вернуться к log4j, вы можете сделать это в течение нескольких минут, просто перетащив slf4j-log4j12.jar на свой путь к классу.

При переходе с logback на log4j отдельные части logback, в частности те, которые содержатся в файле конфигурации logback.xml, все равно необходимо будет перенести в его эквивалент log4j, то есть log4j.properties. При переходе в обратном направлении конфигурацию log4j, то есть log4j.properties, необходимо преобразовать в ее эквивалент при регистрации. Для этого существует интерактивный инструмент. Объем работы, связанной с переносом файлов конфигурации, намного меньше, чем работа, необходимая для переноса вызовов регистратора, распространяемых по всему исходному коду вашего программного обеспечения и его зависимостям.

Вы должны? Да.

Почему? Log4J по существу устарел Вернуться.

Это срочно? Может быть нет.

Это безболезненно? Возможно, но это может зависеть от ваших записей в журнале.

Обратите внимание: если вы действительно хотите в полной мере использовать LogBack (или SLF4J), вам действительно нужно написать правильное ведение журнала заявления. Это даст такие преимущества, как более быстрый код из-за ленивой оценки и меньше строк кода, потому что вы можете избежать защиты.

Наконец, я очень рекомендую SLF4J. (Зачем воссоздавать колесо с собственным фасадом?)

В мире журналирования есть фасады (например, Apache Commons Logging, slf4j или даже Log4j 2.0 API) и их реализации (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

По сути, вы должны заменить свою самодельную оболочку на slf4j IF и только ЕСЛИ она вам по какой-то причине не нравится. Хотя Apache Commons Logging на самом деле не предоставляет современный API, slf4j и новый фасад Log4j 2 предоставляют это. Учитывая, что довольно много приложений используют slf4j в качестве оболочки, имеет смысл использовать это.

slf4j дает несколько приятных API-интерфейсов, как в этом примере из документации slf4j:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

Это подстановка переменных. Это также поддерживается Log4j 2.

Однако вам нужно знать, что slf4j разработан QOS, который также поддерживает логбэк. Log4j 2.0 запечен в Apache Software Foundation. За последние три года здесь снова выросло яркое и активное сообщество. Если вы цените Open Source, как это делается Apache Software Foundation со всеми его гарантиями, вы можете пересмотреть использование slf4j в пользу использования Log4j 2 напрямую.

Пожалуйста, обрати внимание:

Раньше log4j 1 активно не поддерживался, в то время как Logback поддерживался. Но сегодня все по-другому. Log4j 2 активно поддерживается и выпускается почти регулярно. Он также включает в себя множество современных функций и -imho- делает пару вещей лучше, чем Logback. Иногда это просто вопрос вкуса, и вы должны делать собственные выводы.

Я написал краткий обзор новых возможностей Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html.

При чтении вы увидите, что Log4j 2 был вдохновлен Logback, но также и другими фреймворками ведения журналов. Но кодовая база другая; он почти ничего не разделяет с Log4j 1 и ноль с Logback. Это привело к некоторым улучшениям, например, в примере Log4j 2 под капотом работает с байтовыми потоками вместо строк. Также он не теряет события при перенастройке.

Log4j 2 может вести журнал с большей скоростью, чем другие известные мне фреймворки: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html.

И все же сообщество пользователей кажется намного больше, чем Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

Тем не менее, лучшая идея - выбрать те фреймворки ведения журналов, которые лучше всего подходят для того, чего вы хотите достичь. Я бы не переключился на полную структуру, если бы отключил ведение журнала в производственной среде и просто выполнял базовое ведение журнала в своем приложении. Однако, если вы сделаете немного больше с ведением журнала, просто посмотрите на функции, которые предоставляются фреймворками и их разработчиками. Хотя вы получаете коммерческую поддержку Logback через QOS (я слышал), в настоящее время нет коммерческой поддержки для Log4j 2. С другой стороны, если вам нужно вести журнал аудита и вам нужна высокая производительность, обеспечиваемая асинхронными приложениями, имеет смысл проверьте log4j 2.

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

Не зная своих требований лучше, дать рекомендации практически невозможно. Просто: не переключайтесь только потому, что многие люди переключаются. Переключайтесь только потому, что видите в этом ценность. И аргументация о том, что log4j мертв, больше не в счет. Он живой и горячий.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ. В настоящее время я являюсь вице-президентом Apache Logging Services, а также участвую в log4j.

Не совсем отвечаю на ваш вопрос, но если вы можете отказаться от своей самодельной оболочки, тогда есть Simple Logging Facade для Java (SLF4J ), на который теперь переключился Hibernate (вместо обычного ведения журнала).

SLF4J не страдает ни одной из проблем с загрузчиком классов или утечек памяти, наблюдаемых при ведении журнала Jakarta Commons (JCL).

SLF4J поддерживает ведение журнала JDK, log4j и возврат. Так что тогда будет довольно легко переключиться с log4j на логбэк, когда придет время.

Изменить: Aplogies, которые я не прояснил. Я предлагал использовать SLF4J, чтобы изолировать себя от необходимости делать трудный выбор между log4j или logback.

Ваше решение должно основываться на

• ваша реальная потребность в этих «дополнительных функциях»; и
• ваша ожидаемая стоимость внедрения изменения.

Вы должны сопротивляться желанию изменить API только потому, что он «новее, ярче, лучше». Я придерживаюсь политики «если он не сломан, не пинайте его».

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

Зрелый проект или даже проект, находящийся на стадии разработки, вероятно, потеряет больше, чем выгоду от такого обновления, ИМХО. Логбэк, безусловно, намного более продвинут по множеству точек, но не до такой степени, чтобы полностью заменить в работающей системе. Я бы, конечно, рассмотрел возможность входа в систему для новой разработки, но существующий log4j достаточно хорош и зрел для всего, что уже выпущено и встречено конечным пользователем. Это очень субъективно, стоимость вы должны увидеть сами.