Перейти к основному содержимому

Введение в SLF4J

· 5 мин. чтения

1. Обзор​

Простой фасад ведения журналов для Java (сокращенно SLF4J) выступает в качестве фасада для различных сред ведения журналов (например, java.util.logging, logback, Log4j ). Он предлагает общий API, что делает ведение журнала независимым от фактической реализации.

Это позволяет сосуществовать различным платформам ведения журналов. И это помогает переходить с одного фреймворка на другой. Наконец, помимо стандартизированного API, он также предлагает некоторый «синтаксический сахар».

В этом руководстве обсуждаются зависимости и конфигурация, необходимые для интеграции SLF4J с Log4j, Logback, Log4j 2 и Jakarta Commons Logging.

Для получения дополнительной информации о каждой из этих реализаций ознакомьтесь с нашей статьей Introduction to Java Logging .

2. Настройка Log4j 2​

Чтобы использовать SLF4J с Log4j 2, мы добавляем в pom.xml следующие библиотеки :

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.7</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.7</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j-impl</artifactId>
    <version>2.7</version>
</dependency>

Последнюю версию можно найти здесь: log4j-api , log4j-core , log4j-slf4j-impl .

Фактическая конфигурация ведения журнала соответствует собственной конфигурации Log4j 2.

Давайте посмотрим, как создать экземпляр Logger : 

public class SLF4JExample {

    private static Logger logger = LoggerFactory.getLogger(SLF4JExample.class);

    public static void main(String[] args) {
        logger.debug("Debug log message");
        logger.info("Info log message");
        logger.error("Error log message");
    }
}

Обратите внимание, что Logger и LoggerFactory принадлежат пакету org.slf4j .

Пример проекта, работающего с такой конфигурацией, доступен здесь .

3. Настройка логбэка​

Нам не нужно добавлять SLF4J в наш путь к классам, чтобы использовать его с Logback, поскольку Logback уже использует SLF4J. Это эталонная реализация.

Итак, нам просто нужно подключить библиотеку Logback:

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.2.6</version>
</dependency>

Последнюю версию можно найти здесь: logback-classic .

Конфигурация специфична для Logback, но без проблем работает с SLF4J. Имея правильные зависимости и конфигурацию, мы можем использовать тот же код из предыдущих разделов для обработки ведения журнала.

4 . Настройка Log4j​

В предыдущих разделах мы рассмотрели вариант использования, когда SLF4J «сидит» поверх конкретной реализации ведения журнала. При таком использовании он полностью абстрагируется от базовой структуры.

Бывают случаи, когда мы не можем заменить существующее решение для ведения журнала, например, из-за сторонних требований. Но это не ограничивает проект только уже используемым фреймворком.

Мы можем настроить SLF4J как мост и перенаправить на него вызовы существующего фреймворка.

Добавим необходимые зависимости для создания моста для Log4j:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>1.7.30</version>
</dependency>

При установленной зависимости (проверьте последнюю версию на log4j-over-slf4j ) все вызовы Log4j будут перенаправлены на SLF4J.

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

Как и в случае с другими платформами, Log4j может служить базовой реализацией.

Добавим необходимые зависимости:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.30</version>
</dependency>
<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

Вот последние версии для slf4j-log4j12 и log4j . Пример проекта, настроенного таким образом, доступен здесь .

5. Настройка моста JCL​

В предыдущих разделах мы показали, как использовать одну и ту же кодовую базу для поддержки ведения журнала с использованием разных реализаций. Хотя это главное обещание и сила SLF4J, это также цель JCL (Jakarta Commons Logging или Apache Commons Logging).

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

SLF4J разрешает свои привязки во время компиляции. Он воспринимается как более простой, но достаточно мощный.

К счастью, два фреймворка могут работать вместе в режиме моста:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>1.7.30</version>
</dependency>

Последнюю версию зависимости можно найти здесь: jcl-over-slf4j .

Как и в других случаях, одна и та же кодовая база будет работать нормально. Пример полного проекта с этой установкой доступен здесь .

6. Дополнительные функции SLF4J​

SLF4J предоставляет дополнительные функции, которые могут сделать ведение журнала более эффективным, а код — более читаемым.

Например, SLF4J предоставляет очень удобный интерфейс для работы с параметрами:

String variable = "Hello John";
logger.debug("Printing variable value: {}", variable);

Вот код Log4j, делающий то же самое:

String variable = "Hello John";
logger.debug("Printing variable value: " + variable);

Как мы видим, Log4j будет объединять строки независимо от того , включен уровень отладки или нет. В приложениях с высокой нагрузкой это может вызвать проблемы с производительностью. С другой стороны, SLF4J будет объединять строки только тогда, когда включен уровень отладки .

Чтобы сделать то же самое с Log4J, нам нужно добавить дополнительный блок if , который будет проверять , включен ли уровень отладки : 

String variable = "Hello John";
if (logger.isDebugEnabled()) {
    logger.debug("Printing variable value: " + variable);
}

SLF4J стандартизировал уровни ведения журнала, которые различаются для конкретных реализаций. Он снижает уровень ведения журнала FATAL (представленный в Log4j) на основании предположения, что в структуре ведения журнала мы не должны решать, когда завершать приложение.

Используемые уровни ведения журнала: ERROR , WARN , INFO , DEBUG и TRACE . Подробнее об их использовании читайте в нашем Introduction to Java Logging .

7. Заключение​

SLF4J помогает с автоматическим переключением между платформами ведения журналов. Он простой, но гибкий и позволяет повысить удобочитаемость и производительность.

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