перенос проекта из log4j в slf4j + log4j - PullRequest
Новая
       12

перенос проекта из log4j в slf4j + log4j

12 голосов
/ 11 марта 2011

У меня большой веб-проект, который напрямую использует log4j, вместе со многими сторонними библиотеками и набором библиотек журналов.

  • наша кодовая база - напрямую использует log4j.
  • Hibernate - использует slf4j и привязку slf4j-log4j.
  • Spring - использует обыкновенные логи. Таким образом, он использует ji-over-slf4j-мост api, сам slf4j и привязку slf4j-log4j.
  • Другие многочисленные библиотеки, использующие либо общие журналы, либо log4j.

Я подумываю о переносе нашей собственной базы кода на slf4j api, но я не уверен, что преимущества достаточно сильны и стоят усилий. В настоящее время мне известны следующие преимущества:

  • Очиститель API.
  • Улучшения производительности, а именно возможность использования параметризованных методов ведения журнала.
  • Возможность легко переключаться на вход в систему в будущем (в настоящее время выход из системы исключен).
  • Нет необходимости в дополнительных банках, так как они у меня уже есть.

Есть ли другие преимущества? Есть ли какие-то недостатки, о которых я еще не знаю?

Ответы [ 2 ]

6 голосов
/ 11 марта 2011

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

Вероятно, главная причина, по которой я перешел на slf4j (это относится только к slf4j + logback), заключается в том, что вы можете перезагрузить конфигурацию через JMX , что здорово, когда у вас исчезает проблемас перезагрузкой сервера.

5 голосов
/ 06 сентября 2011

Для меня было четыре «убийственные» функции, которые стоили боли при переходе на Logback, помимо тех, что вы уже упоминали (я лично переключил свой текущий крупный проект, работая без нареканий):

  • Автоматическая перезагрузка конфигурационных файлов. Это замечательно для производственных систем.Если вы просто хотите установить «отладку» для одного класса, но не разрушать всю систему, этот будет бесценным.
  • Возможность использования включаемых файлов в конфигурации. Это позволяет вамиметь «главный» набор параметров ведения журнала для всех ваших служб / JVM, а затем вы можете указать любые пакеты, которые могут потребовать специальной обработки.Сейчас у нас около 10 сервисов, и у них есть большая, но в основном похожая копия log4j.xml.Теперь мы изменили его на один главный файл конфигурации logback и включили этот файл в файл конфигурации logback каждой службы.Главный файл все равно будет большим, но для сервисов он должен быть очень маленьким.Гораздо более удобен для обслуживанияодна конфигурация, которая не должна меняться между рабочими и dev / QA серверами.
  • Автоматическое сжатие и удаление старых файлов журнала. Вы можете указать, сколько архивных файлов вы хотите сохранитьи, необязательно, сжать их. После создания файла n + 1 он обнаружит, что его слишком много, и удалит самый старый. Опять же, настраивается для каждого файла / службы, нет необходимости делать что-либо специфичное для системы (пакетные файлы и/ или скрипты).

Кстати, после этого изменения тривиально легко переключиться обратно на log4j. Так как переход на Logback требует использования SLF4J, который также поддерживает Log4j, переключаясь только туда и обратнотребует, чтобы вы выбрали, какой файл jar удалить (Log4j или Logback's). Пока соответствующие файлы конфигурации log4j.xml или logbackв пути к классам ведение журнала будет работать правильно.

...