JCL

The full name is Jakarta common logging, which is a general logging API provided by Apache. It provides a unified interface for "all Java log implementations". It also provides a log implementation itself, but the function is very often weak (SimpleLog). Therefore, it is generally not used alone. It allows developers to use different log implementation tools: Log4j, Jdk's own log (JUL). JCL is an interface, which depends on other log implementations.

Import dependency:

 <dependency>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
      <version>1.2</version>
    </dependency>

Looking at the source code, we can see that the class results are very simple, mainly including Log and LogFactory. The specific implementation classes of Log are

  The Log function is relatively simple. You can switch the Log framework through different implementations, and JCL is less used.

Slf4j

Simple logging facade for Java Slf4j mainly aims to provide a set of standard and standardized API framework for Java log access. Its main significance is to provide interfaces. The specific implementation can be handed over to other log frameworks, such as log4j and logback. Of course, slf4j also provides a relatively simple implementation, but it is rarely used. For general Java projects, the log framework will choose slf4j API The facade is equipped with specific implementation frameworks (log4j, logback, etc.), and the bridge is used to complete the bridge in the middle.

Slf4j defines the log interface, and its own simple implementation

<!--slf4j core use slf4j Must add-->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.28</version>
    </dependency>
    <!--slf4j Self contained simple log implementation -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
      <version>1.7.12</version>
    </dependency>

The slf4j API interface class is relatively simple   Logger and ILoggerFactory.

Since we use slf4j and generally do not use its own simple implementation, we will simply test it.

Benefits of using slf4j API:

1. Using SLF4J framework, you can migrate to the required logging framework during deployment.  

2. SLF4J provides binding to all popular logging frameworks, such as log4j, JUL, Simple logging and NOP. Therefore, you can switch to any of these popular frameworks during deployment.  

3. No matter which binding is used, SLF4J supports parameterized logging messages. Since SLF4J separates the application from the logging framework, it is easy to write applications independent of the logging framework. There is no need to worry about the logging framework used to write applications.  

4. SLF4J provides a simple Java tool called Migrator. With this tool, you can migrate existing projects to SLF4J using logging frameworks (such as Jakarta common logging (JCL) or log4j or Java.util.logging(JUL)).

Binding log

As mentioned earlier, SLF4J supports various logging frameworks. The SLF4J distribution comes with several jar files called "SLF4J binding", and each binding corresponds to a supported framework.

Log binding process using slf4j:

1. Add slf4j API dependency

2. Use slf4j's API for unified logging in the project

3. Bind the specific log implementation framework. 1. Bind the log framework that has implemented slf4j and directly add corresponding dependencies. 2. Bind the log framework that does not implement slf4j, first add the log adapter, and then add the dependency of the implementation class

4. slf4j has only one log implementation framework binding (if there are multiple, the first log implementation is used by default)

Introduce the corresponding log implementation and binding dependency

<!--slf4j core use slf4j Must add-->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.28</version>
    </dependency>
    <!-- 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>
    <!-- jul -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jdk14</artifactId>
      <version>1.7.25</version>
    </dependency>
    <!--jcl -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jcl</artifactId>
      <version>1.7.27</version>
    </dependency>
    <!-- nop -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-nop</artifactId>
      <version>1.7.27</version>
    </dependency>

It can be seen that slf4j API has different adapters when binding different log implementations, and log4j and jcl should be switched through the adapter.

SLF4J does not depend on any special class loading. In fact, each SLF4J binding is hardwired at compile time to use one and only one specific logging framework. Just place the one and only one binding you select in the corresponding classpath location. Do not place multiple bindings on the classpath.

slf4j principle

1. SLF4J loads log specific implementation objects through LoggerFactory.

2. During the initialization of loggerfactory, the specific log implementation will be bound through the performeinitialization () method.

3. When binding the specific implementation, load org/slf4j/impl/StaticLoggerBinder.class through the class loader

4. Therefore, as long as it is a log implementation framework, provide its own StaticLoggerBinder class in org.slf4j.impl package, and the LoggerFactory that provides specific log implementation can be loaded by SLF4J.

You can take a look at the class structure of the above two adaptation dependencies

logback is rarely used at present and can be skipped directly.

For details, please refer to: Logback Home