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

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

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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

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

  • Автоматическая перезагрузка конфигурационных файлов. Это классно для производственных систем. Если вы просто хотите установить "debug" в один класс, но не сбиваете всю систему, это бесценно.
  • Возможность использования файлов include в конфигурации.. Это позволяет вам иметь "главный" набор параметров ведения журнала для всех ваших служб /JVM, а затем вы можете указать любые пакеты, которые могут потребовать специальных обработка. В настоящее время у нас около ~ 10 сервисов, и у них есть большая, но в основном аналогичная, копия log4j.xml. Теперь мы меняем его на один файл конфигурации основного журнала и включаем этот файл в каждый конфигурационный файл журнала обслуживания. Главный файл по-прежнему будет большим, но специфические для обслуживания должны быть очень маленькими. Гораздо удобнее обслуживать.
  • Условная обработка.. Таким образом вы можете указать такие вещи, как "если QAServer = > , а затем установить уровни ведения журнала на" DEBUG ", иначе" INFO ". Опять же, отлично подходит для одной конфигурации, t необходимо изменить между серверами производства и dev/QA.
  • Автоматическое сжатие и удаление старых файлов журнала. Вы можете указать, сколько архивных файлов вы хотите сохранить и, возможно, сжать их. После создания файла n + 1 он обнаружит, что там слишком много, и удалит самый старый. Опять же, настраивается для каждого файла/службы, нет необходимости делать какие-либо системные (командные файлы и/или скрипты).

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