logback звучит очень похоже на регистрацию в Джакарте - каковы основные отличия?
Мэтт б
12
SLF4J (который является фасадом) звучит похоже на commons.logging. Основное отличие заключается в том, что SLF4J использует статическую привязку, а commons.logging использует некоторую стратегию разрешения. Logback («родная» (т. Е. Не реализована дополнительная оболочка) реализация фасада) сравнима с LOG4J, но имеет более богатый API.
Хуси
Ответы:
190
Logback изначально реализует API SLF4J. Это означает, что если вы используете logback, вы на самом деле используете API SLF4J. Теоретически вы могли бы использовать внутреннюю часть API logback напрямую для регистрации, но это крайне не рекомендуется. Вся документация по возврату и примеры на регистраторах написаны с точки зрения API SLF4J.
Таким образом, используя logback, вы на самом деле будете использовать SLF4J, и если по какой-либо причине вы захотите переключиться обратно на log4j, вы можете сделать это в течение нескольких минут, просто поместив slf4j-log4j12.jar в путь к классам.
При переходе от logback к log4j определенные части logback, особенно те, которые содержатся в файле конфигурации logback.xml, все равно должны быть перенесены в его эквивалент log4j, то есть log4j.properties . При переносе в другом направлении, конфигурация log4j, то есть log4j.properties , должна быть преобразована в эквивалентный logback. Для этого есть онлайн-инструмент . Объем работ, выполняемых при переносе файлов конфигурации, намного меньше, чем объем работ, необходимых для переноса вызовов регистратора, распространяемых по всему исходному коду вашего программного обеспечения и его зависимостям.
Это безболезненно? Возможно, но это может зависеть от ваших заявлений регистрации.
Обратите внимание, что если вы действительно хотите в полной мере использовать преимущества LogBack (или SLF4J), то вам действительно необходимо написать правильные операторы ведения журнала. . Это даст такие преимущества, как более быстрый код из-за ленивых вычислений и меньше строк кода, потому что вы можете избежать защиты.
Наконец, я очень рекомендую SLF4J. (Зачем воссоздавать колесо с собственным фасадом?)
Примечание. Проект log4j не считает log4j устаревшим.
Торбьерн Равн Андерсен
17
Терминология должна быть уточнена; однозначно, то автор проекта log4j считает Logback быть преемником в log4j. Это один и тот же автор обоих проектов, поэтому его мнение должно иметь некоторый вес; Сам проект «log4j» ничего не «учитывает». Нынешняя группа людей, связанных с log4j, имеет разные мнения (некоторые на самом деле согласны, некоторые неудивительно, что не согласны). С небольшой историей позади (через 3 года после первоначального комментария) SLF4J + Logback продолжают завоевывать позиции над Log4j.
Майкл
@michael_n Обратите внимание, что Log4j 1 не был написан одним человеком. Неправильно говорить «тот же автор». Цеки является важным автором, без сомнения, но не единственным. На самом деле многие люди помогли сделать Log4j 1 таким, какой он есть.
Кристиан
@Christian "НЕ был написан ...", конечно, это должно подразумеваться для любого зрелого проекта Apache (и моя квалификация, "текущая группа людей, связанных с log4j"); тем не менее, если бы я мог отредактировать комментарий, я бы сказал « изначально автор», как говорится в статье в Википедии. Re: «На самом деле многие люди помогли сделать Log4j 1 таким, какой он есть» , это абсолютно, двусмысленно (то есть, к лучшему или к худшему); а также, в некотором роде, способствовал возникновению slf4j + logback :-)
Майкл
3
Итак, что же для вас всех в борьбе за ту или иную библиотеку журналов? Почему мы пытаемся убить / продвинуть библиотеки? По крайней мере, предоставьте некоторые рациональные рассуждения, почему одно лучше, чем другое. Боже, переполнение стека это беспорядок.
Пользователь
48
В мире ведения журналов есть Фасады (такие как 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, который также поддерживает logback. Log4j 2.0 запекается в Apache Software Foundation. За последние три года там снова выросло активное и активное сообщество. Если вы цените Open Source, как это делает Apache Software Foundation со всеми его гарантиями, вы можете пересмотреть использование slf4j в пользу непосредственного использования Log4j 2.
Пожалуйста, обратите внимание:
В прошлом log4j 1 активно не поддерживался, в то время как Logback был. Но сегодня все иначе. Log4j 2 активно поддерживается и выпускается практически по расписанию. Он также включает в себя множество современных функций и -imho- делает несколько вещей лучше, чем Logback. Иногда это просто вопрос вкуса, и вы должны сделать свои собственные выводы.
При чтении вы увидите, что Log4j 2 был вдохновлен Logback, а также другими платформами журналирования. Но кодовая база другая; он почти ничего не делит с Log4j 1 и ноль с Logback. Это приводит к некоторым улучшениям, как, например, в примере Log4j 2 работает с потоками байтов вместо строк под капотом. Также он не теряет события при перенастройке.
Тем не менее, лучшая идея заключается в том, что вы выбираете каркас логирования, который лучше всего соответствует тому, чего вы хотите достичь. Я бы не стал переключать полную инфраструктуру, если бы отключил ведение журналов в производственной среде и просто выполнял базовые журналы в своем приложении. Однако, если вы сделаете немного больше с регистрацией, просто посмотрите на функции, предоставляемые фреймворками и их разработчиками. В то время как вы получаете коммерческую поддержку Logback через QOS (я слышал), в настоящее время нет коммерческой поддержки Log4j 2. С другой стороны, если вам нужно вести журнал аудита и вам нужна высокая производительность, обеспечиваемая асинхронными приложениями, то имеет смысл проверьте log4j 2.
Пожалуйста, обратите внимание, что несмотря на весь комфорт, который они обеспечивают, фасады всегда выглядят малоэффективно. Возможно, это совсем не влияет на вас, но если у вас мало ресурсов, вам может понадобиться сохранить все, что вы можете иметь.
Не зная ваших требований лучше, почти невозможно дать рекомендацию. Просто: не переключайтесь только потому, что многие люди переключаются. Переключайтесь только потому, что видите его значение. И аргументация того, что log4j мертва, больше не считается. Он живой и горячий.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: В настоящее время я являюсь вице-президентом Apache Logging Services, а также занимаюсь log4j.
Не совсем отвечая на ваш вопрос, но если вы можете отойти от своей собственной обертки, то есть Simple Logging Facade для Java (SLF4J), на который Hibernate теперь переключился (вместо регистрации общих).
SLF4J не страдает ни от каких проблем загрузчика классов или утечек памяти, наблюдаемых при Jakarta Commons Logging (JCL).
SLF4J поддерживает ведение журнала JDK, log4j и logback. Так что тогда будет достаточно легко переключиться с log4j на logback, когда придет время.
Редактировать: Аплоги, которые я не дал себе понять. Я предлагал использовать SLF4J, чтобы изолировать себя от необходимости делать трудный выбор между log4j или logback.
Извиняюсь. Я предлагал, что если бы вы использовали SLF4J вместо собственного пользовательского фасада, то переключение с log4j на logback было бы менее болезненным?
Инструментарий
Каков источник этой цитаты? Ведение журнала Commons является проверенным и проверенным компонентом. У меня никогда не было утечек памяти.
Кшитиз Шарма
1
@KshitizSharma - из ссылки на документацию по SLF4J, которую я предоставил: slf4j.org/manual.html
инструментарий
13
Ваше решение должно основываться на
ваша фактическая потребность в этих «дополнительных функциях»; и
ваши ожидаемые затраты на внедрение изменений.
Вы должны сопротивляться желанию изменить API только потому, что оно «новее, блестяще, лучше». Я придерживаюсь политики «если это не сломано, не пинайте это».
Если вашему приложению требуется очень сложная структура ведения журнала, вы можете подумать, почему.
ИМХО, зрелый проект или даже проект, находящийся глубоко в стадии разработки, вероятно, потеряет больше, чем выгоду от такого обновления. Logback, конечно, намного более продвинут в массиве точек, но не настолько, чтобы полностью заменить работающую систему. Я бы, конечно, рассмотрел logback для новой разработки, но существующий log4j достаточно хорош и подходит для всего, что уже выпущено и встречено конечным пользователем. Это очень субъективно, вы должны увидеть стоимость себя.
Ответы:
Logback изначально реализует API SLF4J. Это означает, что если вы используете logback, вы на самом деле используете API SLF4J. Теоретически вы могли бы использовать внутреннюю часть API logback напрямую для регистрации, но это крайне не рекомендуется. Вся документация по возврату и примеры на регистраторах написаны с точки зрения API SLF4J.
Таким образом, используя logback, вы на самом деле будете использовать SLF4J, и если по какой-либо причине вы захотите переключиться обратно на log4j, вы можете сделать это в течение нескольких минут, просто поместив slf4j-log4j12.jar в путь к классам.
При переходе от logback к log4j определенные части logback, особенно те, которые содержатся в файле конфигурации logback.xml, все равно должны быть перенесены в его эквивалент log4j, то есть log4j.properties . При переносе в другом направлении, конфигурация log4j, то есть log4j.properties , должна быть преобразована в эквивалентный logback. Для этого есть онлайн-инструмент . Объем работ, выполняемых при переносе файлов конфигурации, намного меньше, чем объем работ, необходимых для переноса вызовов регистратора, распространяемых по всему исходному коду вашего программного обеспечения и его зависимостям.
источник
Вы должны? Да .
Зачем? Log4J по существу устарел из-за Logback .
Это срочно? Может быть нет.
Это безболезненно? Возможно, но это может зависеть от ваших заявлений регистрации.
Обратите внимание, что если вы действительно хотите в полной мере использовать преимущества 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, который также поддерживает logback. 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 поддерживает ведение журнала JDK, log4j и logback. Так что тогда будет достаточно легко переключиться с log4j на logback, когда придет время.
Редактировать: Аплоги, которые я не дал себе понять. Я предлагал использовать SLF4J, чтобы изолировать себя от необходимости делать трудный выбор между log4j или logback.
источник
Ваше решение должно основываться на
Вы должны сопротивляться желанию изменить API только потому, что оно «новее, блестяще, лучше». Я придерживаюсь политики «если это не сломано, не пинайте это».
Если вашему приложению требуется очень сложная структура ведения журнала, вы можете подумать, почему.
источник
ИМХО, зрелый проект или даже проект, находящийся глубоко в стадии разработки, вероятно, потеряет больше, чем выгоду от такого обновления. Logback, конечно, намного более продвинут в массиве точек, но не настолько, чтобы полностью заменить работающую систему. Я бы, конечно, рассмотрел logback для новой разработки, но существующий log4j достаточно хорош и подходит для всего, что уже выпущено и встречено конечным пользователем. Это очень субъективно, вы должны увидеть стоимость себя.
источник