Стоит ли использовать slf4j с log4j2

114

Я не могу решить, использовать ли slf4j с log4j2 или нет. Судя по онлайн-сообщениям, не похоже, что это повлияет на производительность, но действительно ли это необходимо.

Также эти пункты правят в пользу log4j2:

SLF4J заставляет ваше приложение регистрировать строки. API Log4j 2 поддерживает регистрацию любого CharSequence, если вы хотите регистрировать текст, но также поддерживает регистрацию любого объекта как есть.
API Log4j 2 предлагает поддержку для ведения журнала объектов сообщений, лямбда-выражений Java 8 и ведения журнала без мусора (он позволяет избежать создания массивов vararg и позволяет избежать создания строк при регистрации объектов CharSequence).

— Энди897
источник

Может быть. Что делать, если мой сервер приложений включает slf4jи логбэк (или log4jv1)? Должен ли я быть вынужден установить третий регистратор для использования вашего приложения? Или, может быть, корпоративная безопасность решит, что вы можете использовать только java.util.loggingв производстве, что тогда?

— Эллиотт Фриш

Спасибо за письмо. Но, если все используют log4j org wide, приведенный выше аргумент не будет действительным.

— Andy897

Использование SLF4J означает, что заменить реализацию очень легко, если политика компании изменится, например, когда ваша компания приобретена и вам навязывают новую политику. Использование SLF4J сейчас, когда вы пишете код, займет не больше времени, чем использование Log4j напрямую. Замена прямых вызовов Log4j позже займет много времени. SLF4J - это бесплатное вложение / страховка на будущее. Это более важно, чем функции API Log4j 2? Это можете решить только вы (или политика компании).

— Андреас

Есть ли вообще способ использовать slf4j с log4j2, если хотите? На этой странице показано использование с log4j (версия 1.2), срок службы которого истек), но без опции для log4j2. Если есть способ, почему slf4j не упоминает о нем?

— J

162

Вперед: запрограммируйте API log4j2 вместо slf4j

Это безопасно: API Log4j2 предлагает те же гарантии, что и slf4j, и даже больше.

Теперь, когда сам Log4j2 разделен на API и модуль реализации, использование SLF4J больше не имеет смысла.

Да, это хорошая инженерная практика - оставлять ваши варианты открытыми. Позже вы можете захотеть перейти на другую реализацию ведения журнала.

Последние 10 лет или около того создание такой гибкости в вашем приложении означало использование API-оболочки, такого как SLF4J. Однако такая гибкость не дается бесплатно: недостатком такого подхода является то, что ваше приложение не может использовать более богатый набор функций базовой библиотеки журналирования.

Log4j2 предлагает решение, которое не требует, чтобы ваше приложение ограничивалось наименьшим общим знаменателем.

Запасной клапан: log4j-to-slf4j

Log4j2 включает log4j-to-slf4jмодуль моста. Любое приложение, написанное с использованием API Log4j2, может в любой момент переключить поддерживающую реализацию на любую slf4j-совместимую реализацию.

Как упоминалось в вопросе, использование API-интерфейса Log4j2 напрямую предлагает больше функций и имеет некоторые нефункциональные преимущества по сравнению с использованием API-оболочки, например slf4j:

API сообщений
Лямбды для ленивого ведения журнала
Записывать любой объект, а не только строки
Без мусора: избегайте создания переменных или строк, где это возможно
CloseableThreadContext автоматически удаляет элементы из MDC, когда вы закончите с ними

(Подробнее см. 10 функций API Log4j2, недоступных в SLF4J .)

Приложения могут безопасно использовать эти богатые возможности API Log4j2 без привязки к собственной реализации ядра Log4j2.

SLF4J по-прежнему является вашим предохранительным клапаном, это просто не означает, что ваше приложение больше не должно кодировать API SLF4J.

Раскрытие информации: я участвую в Log4j2.

Обновление: похоже, есть некоторая путаница в том, что программирование API Log4j2 каким-то образом вводит «фасад для фасада». В этом отношении нет разницы между Log4j2 API и SLF4J.

Оба API требуют 2 зависимости при использовании нативной реализации и 4 зависимости для неродной реализации. SLF4J и Log4j2 API в этом отношении идентичны. Например:

Требуемые зависимости аналогичны для SLF4J и Log4j 2 API.

— Ремко Попма
источник

Я понимаю. Позвольте мне перефразировать свой вопрос. Существуют ли какие-либо независимые реализации API log4j2, кроме log4j2?

— Ceki

API Log4j2 и impl не являются «тесно связанными». Доступны все эти реализации SLF4J: приложение, написанное с использованием API Log4j2, может выбрать log4j-to-slf4jзависимость вместо log4j-coreи выбрать любую из этих реализаций SLF4J, которые вы упомянули. Количество встроенных реализаций API Log4j2 значения не имеет.

— Ремко

Проблема в том, что у вас часто есть зависимости от библиотек, которые сами используют slf4j, поэтому проще придерживаться этого.

— Давио

Итак, я должен использовать интерфейс для интерфейса для реализации? Да, нет, спасибо ... Slf4j превзошел log4j, предоставив хороший интерфейс для реализации для ведения журнала ... log4j2 должен просто реализовать slf4j api - если есть отсутствующая функция, внесите ее обратно, если slf4j не возьмет новый функция, тогда МОЖЕТ БЫТЬ случай для интерфейсов api log4j2 ....

— RockMeetHardplace

@RemkoPopma - вы все еще выступаете против использования интерфейса log4j. Да, я понял - я могу связать интерфейс log4j2 -> интерфейс slf4j -> любую реализацию, но я бы предпочел не абстрагировать абстракцию - спасибо, но нет, спасибо.

— RockMeetHardplace