SLF4J,Logback,Commons Logging,Log4j

Simple Logging Facade for Java (SLF4J) Simple Logging Facade

As the name suggests, it uses facade mode

Facade Pattern, also known as appearance Pattern, is the full English name of Facade Design Pattern

In GoF’s Book Design Patterns, the facade pattern is defined as follows:

Provide a unified interface to a set of interfaces in a subsystem.

Facade Pattern defines a higher-level interface that makes the subsystem easier to use.

The facade pattern provides a unified set of interfaces for the subsystem and defines a set of high-level interfaces to make the subsystem easier to use.

The “subsystem” in the facade pattern definition can also be understood in a variety of ways. It can be a complete system or a more fine-grained class or module.

I’m not referring to interfaces in Java, but to services provided by layers or layers

It is easy to understand that SLF4J is not a specific logging solution, but serves a variety of logging frameworks

This figure shows how SLF4J binds other logging components

As can be seen from the figure, SLF4J has another layer of encapsulation on Logback,Commons Logging,Log4j and other Logging frameworks. When writing code, SLF4J API can be directly called, and the underlying framework can be switched at any time during the actual run without changing the code. JDBC uses the same pattern.

Logback

Here’s a look at Logback in more detail

For the Spring Boot project, in

Rely on the

的

Logback has already been introduced in poM and does not need to be configured in POM

Description of automatic configuration of LogBook in official documentation

Let us begin by discussing the initialization steps that logback follows to try to configure itself:

  1. Logback tries to find a file called logback-test.xml in the classpath.
  2. If no such file is found, logback tries to find a file called logback.groovy in the classpath.
  3. If no such file is found, it checks for the file logback.xml in the classpath.
  4. If no such file is found, service-provider loading facility (introduced in JDK 1.6) is used to resolve the implementation of com.qos.logback.classic.spi.Configurator interface by looking up the file META-INF\services\ch.qos.logback.classic.spi.Configurator in the class path. Its contents should specify the fully qualified class name of the desired Configurator implementation.
  5. If none of the above succeeds, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.

If logback is not found in the classpath, logback.groovy will be found in the classpath. Haven’t found it using the JDK service – the provider in the meta-inf/services/ch. Qos. Logback. Classic. Spi. The Configurator for com. Qos. Logback. Classic. Spi. Confi Gurator’s implementation class, if not already configured with its own BasicConfigurator

<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{36} - %msg%n</pattern> </encoder> </appender> <root level="debug"> <appender-ref ref="STDOUT" /> </root> </configuration>Copy the code

So this is the same thing as the BasicConfigurator

Next, the Logback configuration file

Logback configuration file

The Configuration module contains three appenders, root, and Logger

Both appender and Logger can have zero or more, and root can have only one

For the logger

Includes name as a mandatory parameter and level and additivity as two optional parameters

Level The options are TRACE, DEBUG, INFO, WARN, ERROR, ALL or OFF. INHERITED is mandatory when set to NULL

Logger contains 0 or more appender-ref,
contains a parameter ref through which to specify the appender

Similar to Logger, root is the highest level. It has only one name attribute and can use TRACE, DEBUG, INFO, WARN, ERROR, ALL, or OFF. Root can also have 0 or more appender-refs

example

<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{36} - %msg%n</pattern> </encoder> </appender> <logger name="chapters.configuration" level="INFO"/> <! -- 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>Copy the code

Appender structure

The class parameter specifies the fully qualified class name of the appender implementation class

example

<configuration>
​
  <appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>myApp.log</file>
​
    <encoder>
      <pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern>
    </encoder>
  </appender>
​
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%msg%n</pattern>
    </encoder>
  </appender>
​
  <root level="debug">
    <appender-ref ref="FILE" />
    <appender-ref ref="STDOUT" />
  </root>
</configuration>
Copy the code

I don’t want to write it

The official documentation logback. Qos. Ch/manual/conf…

I read a few blogs and found that log4j2 now seems to perform a little better juejin.cn/post/694575… Juejin. Cn/post / 684490… Decided to write another article on Log4j