Простой фасад ведения журнала для Java (slf4j) — это простой фасад для различных сред ведения журналов, таких как ведение журнала JDK (java.util.logging), log4j или logback. Даже если он содержит привязку, он делегирует все операции ведения журнала другому известному фасаду ведения журнала, который называется Jakarta commons logging (JCL).
Logback является преемником log4j API logger, фактически оба проекта имеют одного и того же отца, но logback предлагает некоторые преимущества по сравнению с log4j, такие как более высокая производительность и меньшее потребление памяти, автоматическая перезагрузка файлов конфигурации или возможности фильтрации, чтобы сослаться на некоторые функции.
Нативная реализация slf4j — это logback, поэтому использование как структуры логгера подразумевает нулевую память и вычислительные затраты.
Сначала мы добавим slf4j и logback в pom как зависимости.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
<properties> <slf4j.version>1.6.4</slf4j.version> <logback.version>1.0.1</logback.version></properties><dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>${logback.version}</version> </dependency></dependencies> |
Обратите внимание, что требуется три файла: один для slf4j и два для входа в систему. Последние две зависимости будут меняться в зависимости от вашей среды ведения журналов, если, например, вы все еще хотите использовать log4j, вместо того, чтобы иметь зависимости logback, у нас были бы сама зависимость log4j и slf4j-log4j12.
Следующим шагом является создание файла конфигурации. Logback поддерживает два формата файлов конфигурации, традиционный способ, используя XML или стиль Groovy DSL. Давайте начнем с традиционного способа, и мы собираемся создать файл с именем logback.xml в classpath. Имя файла обязательно, но logback-test.xml также допустим. В случае, если оба файла найдены в classpath, будет использован файл, заканчивающийся на -test.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<?xml version="1.0" encoding="UTF-8"?><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default --> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n</pattern> </encoder> </appender> <logger name="com.lordofthejars.foo" level="INFO" additivity="false"> <appender-ref ref="STDOUT" /> </logger> <!-- Strictly speaking, the level attribute is not necessary since --> <!-- the level of the root level is set to DEBUG by default. --> <root level="DEBUG"> <appender-ref ref="STDOUT" /> </root> </configuration> |
В общем, файл довольно интуитивно понятен, мы определяем appender (вывод сообщений журнала), в данном случае для консоли, шаблон, и, наконец, регистратор корневого уровня (DEBUG) и регистратор другого уровня (INFO) для классов, присутствующих в foo пакет.
Очевидно, этот формат гораздо удобнее для чтения, чем типичные log4j.properties. Напомним, что по атрибуту аддитивности, приложение с именем STDOUT подключено к двум регистраторам, root и com.lordofthejars.foo. Поскольку корневой регистратор является прародителем всех регистраторов, запрос регистрации, сделанный регистратором com.lordofthejars.foo, будет выведен дважды. Чтобы избежать этого, вы можете установить для атрибута аддитивности значение false, и сообщение будет напечатано только один раз.
Теперь давайте создадим классы, которые будут использовать slf4j. Первый класс с именем BarComponent создается на com.lordofthejars.bar:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
public class BarComponent { private static final Logger logger = LoggerFactory.getLogger(BarComponent.class); public void bar() { String name = "lordofthejars"; logger.info("Hello from Bar."); logger.debug("In bar my name is {}.", name); }} |
Обратите внимание на два больших отличия от log4j. Во-первых, больше не требуется типичная конструкция if над каждым вызовом журнала. Другой является парой ‘{}’. Только после оценки, регистрировать или нет, logback отформатирует сообщение, заменив ‘{}’ на указанное строковое значение.
Другой, называемый FooComponent, создается на com.lordofthejars.foo:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
public class FooComponent { private static final Logger logger = LoggerFactory.getLogger(FooComponent.class); public void foo() { String name = "Alex"; logger.info("Hello from Foo."); logger.debug("In foo my name is {}.", name); }} |
И теперь, вызывая метод foo и bar с предыдущей конфигурацией, получим вывод:
|
1
2
3
|
13:49:59.586 [main] INFO c.l.b.BarComponent - Hello from Bar.13:49:59.617 [main] DEBUG c.l.b.BarComponent - In bar today is 5/3/201213:49:59.618 [main] INFO c.l.f.FooComponent - Hello from Foo. |
Обратите внимание, что строки отладки в методе foo не отображаются. Это нормально, потому что мы настроены так.
Следующим шагом, который мы собираемся предпринять, является настройка logback, но вместо использования XML-подхода мы будем использовать отличный DSL-подход. Logback будет отдавать предпочтение конфигурации groovy, а не конфигурации xml, так что имейте это в виду, если вы смешиваете подходы к настройке.
Итак, первое, что нужно сделать, это добавить Groovy в качестве зависимости.
|
1
2
3
4
5
6
|
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy</artifactId> <version>${groovy.version}</version> <scope>runtime</scope></dependency> |
И тогда мы собираемся создать ту же конфигурацию, созданную ранее, но в отличном формате.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
import ch.qos.logback.classic.encoder.PatternLayoutEncoderimport ch.qos.logback.core.ConsoleAppenderimport static ch.qos.logback.classic.Level.DEBUGimport static ch.qos.logback.classic.Level.INFOappender("STDOUT", ConsoleAppender) { encoder(PatternLayoutEncoder) { pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} Groovy - %msg%n" }}logger("com.lordofthejars.foo", INFO)root(DEBUG, ["STDOUT"]) |
Вы можете идентифицировать те же параметры XML-подхода, но как функции groovy.
Я хотел бы, чтобы вы сочли этот пост полезным, и в следующем проекте, если сможете, используйте slf4j в сочетании с logback, ваше приложение будет работать быстрее, чем вход с log4j.
Ссылка: Использование slf4j с руководством по обратному входу от нашего партнера по JCG Алекса Сото в блоге One Jar To Rule The All .