Log4j против logback
Мы используем log4j за самодельной оберткой. Сейчас мы планируем использовать гораздо больше его возможностей.
Стоит ли обновляться до логбэка?
(Я имею в виду каркас, а не фасад, как SLF4J)
SLF4J (который является фасадом) звучит похоже на commons.logging. Основное отличие состоит в том, что SLF4J использует статическую привязку, в то время как commons.logging использует некоторую стратегию разрешения. Logback («родная» (т.е. без дополнительного слоя оболочки) реализация фасада) сравнима с LOG4J, но имеет более богатый API.
SLF4J - это фасадный фреймворк, который упрощает переключение с одного фреймворка на другой Сравнение Checkout между всеми фреймворками здесь
Ответы 6
Не совсем отвечаю на ваш вопрос, но если вы могли бы отойти от своей самодельной обертки, тогда есть Простой фасад журнала для Java (SLF4J), на который теперь переключился Hibernate (вместо регистрации общего доступа).
SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).
SLF4J поддерживает ведение журнала JDK, log4j и возврат. Так что тогда будет довольно легко переключиться с log4j на логбэк, когда придет время.
Обновлено: Aplogies, которые я не прояснил. Я предлагал использовать SLF4J, чтобы изолировать себя от необходимости делать трудный выбор между log4j или logback.
Я знаю SLF4J. Но каркас сруба просил не для фасада!
Извинения. Я предлагал, чтобы если вы использовали SLF4J вместо своего собственного фасада, то переключение с log4j на logback было бы менее болезненным?
Каков источник этой цитаты? Ведение журнала Commons - это проверенный и проверенный компонент. У меня никогда не было утечек памяти с ним.
@KshitizSharma - из предоставленной мной ссылки документации SLF4J: slf4j.org/manual.html
Ваше решение должно основываться на
- ваша реальная потребность в этих «дополнительных функциях»; и
- ожидаемая стоимость внедрения изменения.
Вы должны сопротивляться желанию изменить API только потому, что он «новее, ярче, лучше». Я придерживаюсь политики «если она не сломана, не пинайте ее».
Если вашему приложению требуется очень сложная структура ведения журнала, вы можете подумать, почему.
Logback изначально реализует SLF4J API. Это означает, что если вы используете логбэк, вы фактически используете SLF4J API. Теоретически вы можете использовать внутреннюю часть API логбэка напрямую для регистрации, но это крайне не рекомендуется. Вся документация по логбэку и примеры для логгеров написаны с использованием SLF4J API.
Таким образом, используя logback, вы на самом деле будете использовать SLF4J, и если по какой-либо причине вы захотите вернуться к log4j, вы можете сделать это в течение нескольких минут, просто перетащив slf4j-log4j12.jar на свой путь к классу.
При переходе с логбэка на log4j отдельные части логбэка, в частности те, которые содержатся в файле конфигурации logback.xml, все равно необходимо будет перенести в его эквивалент log4j, то есть log4j.properties. При переходе в обратном направлении конфигурацию log4j, то есть log4j.properties, необходимо преобразовать в ее эквивалент при регистрации. Для этого есть он-лайн инструмент. Объем работы, связанной с переносом файлов конфигурации, на много меньше, чем объем работы, необходимой для переноса вызовов регистратора, распространяемых по всему исходному коду вашего программного обеспечения и его зависимостям.
Это редкая возможность поговорить с разработчиком столь популярного программного обеспечения. Спасибо Ceki за log4j.
Отказ от ответственности: этот парень является первоначальным разработчиком всех Log4j, SLF4J и Logback. Но больше не работает с Log4j.
Тебе следует? да.
Почему? Log4J по существу устарел Логбэк.
Это срочно? Возможно, нет.
Это безболезненно? Возможно, но это может зависеть от ваших записей в журнале.
Обратите внимание: если вы действительно хотите в полной мере использовать LogBack (или SLF4J), вам действительно нужно написать правильные отчеты о регистрации. Это даст такие преимущества, как более быстрый код из-за ленивой оценки и меньше строк кода, потому что вы можете избежать защиты.
Наконец, я очень рекомендую SLF4J. (Зачем воссоздавать колесо с собственным фасадом?)
Примечание. Проект log4j не считает log4j устаревшим.
Следует уточнить терминологию; однозначно, автор проекта log4j считает войти в систему, чтобы стать преемником log4j. Это один и тот же автор обоих проектов, поэтому его мнение должно иметь определенный вес; сам «проект log4j» ничего не «учитывает». У нынешней группы людей, связанных с log4j, разные мнения (некоторые действительно согласны, некоторые, что неудивительно, не согласны). Имея за плечами немного больше истории (через 3 года после первоначального комментария), SLF4J + Logback продолжает укреплять свои позиции по сравнению с Log4j.
@michael_n Обратите внимание, что Log4j 1 был написан НЕ одним человеком. Неправильно говорить «один и тот же автор». Цеки - важный автор, без сомнения, но не единственный. Фактически, многие люди помогли сделать Log4j 1 тем, чем он является.
@Christian "НЕ был написан ...", конечно, это должно подразумеваться для любого зрелого проекта apache (и моя квалификация - "текущая группа людей, связанных с log4j"); тем не менее, если бы я мог отредактировать комментарий, я бы сказал «Автор изначально», как также говорится в статье в Википедии. Re: «На самом деле многие люди помогли сделать Log4j 1 тем, чем он является», то есть абсолютно, двусмысленно (т.е. в лучшую или в худшую сторону); а также в некоторой степени способствовал возникновению slf4j + logback :-)
Итак, зачем вам всем бороться за ту или иную библиотеку логирования? Почему мы пытаемся убивать / продвигать библиотеки? По крайней мере, приведите рациональные аргументы, ПОЧЕМУ один лучше другого. Боже, переполнение стека - это беспорядок.
Согласен, Маниус. На stackoverflow.com/questions/178836/… есть гораздо более аргументированное обсуждение
Зрелый проект или даже проект, находящийся на стадии разработки, вероятно, потеряет больше, чем выгоду от такого обновления, ИМХО. Логбэк, безусловно, намного более продвинут по множеству точек, но не до такой степени, чтобы полностью заменить в работающей системе. Я бы, конечно, рассмотрел возможность входа в систему для новой разработки, но существующий log4j достаточно хорош и зрел для всего, что уже выпущено и встречено конечным пользователем. Это очень субъективно, стоимость вы должны увидеть сами.
В мире журналирования есть фасады (например, 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.
logback звучит очень похоже на ведение журнала jakarta commons - каковы основные отличия?