• Slf4j integration with JDK-Logging:

  Jar packages required:

  • slf4j-api
  • Slf4j-jdk14 (Integration package)

• Slf4j integration with log4j1:

  Jar packages required:

  • slf4j-api
  • log4j
  • Slf4j-log4j12 (Integration package)

• Slf4j integration with log4j2:

  Jar packages required:

  • slf4j-api
  • log4j-api
  • log4j-core
  • Log4j-slf4j-impl (Integration package)

• Slf4j integration with LogBack:

  Jar packages required:

  • slf4j-api
  • logback-core
  • Logback-classic (Integration Package)

• Slf4j integration with Commons-logging:

  Jar packages required:

  • slf4j-api
  • commons-logging
  • Slf4j-jcl (Integration Package)

See log4J-over-slf4j for an example:

As you can see, this is a simplified and improved version of Log4j. Remove log4j1’s native JAR package and replace it with this simplified and improved jar package (which allows seamless migration).

But the implementation of loggers in the simplified version is different from that in the native version. In the simplified version, loggers are implemented as follows (inheriting categories) :

public class Category { private String name; protected org.slf4j.Logger slf4jLogger; private org.slf4j.spi.LocationAwareLogger locationAwareLogger; Category(String name) { this.name = name; slf4jLogger = LoggerFactory.getLogger(name); if (slf4jLogger instanceof LocationAwareLogger) { locationAwareLogger = (LocationAwareLogger) slf4jLogger; }}}Copy the code

As you can see from above, the simplified version of Logger is generated internally using the SLF4J API, so the simplified version of Logger we use will delegate to SLF4J for output. Since logback-classic is in the current classpath, SLF4J will choose Logback for output. Thus log4j to Logback log switch is realized.

The following sections will only cover switching from the logging system to SLF4J, not what kind of logging SLF4J chooses to output

private static final Logger logger=Logger.getLogger(JulSlf4jLog4jTest.class.getName());

public static void main(String[] args){
    logger.log(Level.INFO,"jul info a msg");
    logger.log(Level.WARNING,"jul waring a msg");
}
Copy the code

As you can see, this was programmed using the JDK-Logging API, and now we want to pass the logs to Logback for output

The solutions are as follows:

• Step 1: Add the following JAR packages:

  • Jul-to-slf4j (implementing JDK-logging switching to SLf4J)
  • slf4j-api
  • logback-core
  • logback-classic

• Step 2: Add the logback configuration file to the classpath

• Step 3: Add the following code to your code:

  static{
      SLF4JBridgeHandler.install();
  }
  Copy the code

We see that there is only one class: SLF4JBridgeHandler

It inherits the JDK – logging defined in Java. Util. Logging. The Handler, Handler is JDK – logging processing log the process of a processor (specific I didn’t also carefully studied), before use, must be registered in advance the processor, Namely the SLF4JBridgeHandler. Install () operation, we can be achieved by the handler after the install log switch work, as follows:

protected Logger getSLF4JLogger(LogRecord record) {
    String name = record.getLoggerName();
    if (name == null) {
        name = UNKNOWN_LOGGER_NAME;
    }
    return LoggerFactory.getLogger(name);
}
Copy the code

In the process of processing logs, slF4J’s native LoggerFactory is used to obtain a Logger defined by SLF4J to output logs

Slf4j, in turn, selects Logback for the actual log output

Jar package used

• commons-logging

Examples are as follows:

private static Log logger=LogFactory.getLog(JulJclTest.class); public static void main(String[] args){ if(logger.isTraceEnabled()){ logger.trace("commons-logging-jcl trace message"); }}Copy the code

As you can see, we are using the COMMONs-logging API for logging. Now we want to switch to logback for logging output (this is actually the integration of Commons-logging and logback).

The solutions are as follows:

• Step 1: Remove the Commons-logging jar package (it doesn’t matter if you go there or not)

• Step 2: Add the following JAR packages:

  • Jcl-over-slf4j (implementing commons-logging switching to SLf4J)
  • slf4j-api
  • logback-core
  • logback-classic

• Step 3: Add the logback configuration file to the classpath

The above log switching principle is clear, the following is for specific examples to apply

Let’s take a look at the official picture of SLF4J:

These three cases are described in detail below

• Status:

  Current applications already use the following hybrid apis for logging programming:

  • commons-logging
  • jdk-logging

  Now you want to uniformly pass the output of the log to log4j1

• Solutions:

  • Step 1: Switch all the logging systems mentioned above to SLF4J seamlessly first

    • Remove commons-logging and switch the underlying logging output to SLf4J using jCL-over-slf4J
    • Switch the juL log output to SLf4J using jul-to-slf4J

  • Step 2: Make SLF4J select log4j1 as the underlying log output

  Add the following JAR packages:

  • slf4j-api
  • log4j
  • Slf4j-log4j12 (Integration package)

Still here is the content of the slF4J official website conflict note

In fact, it is easy to understand the function of each JAR package introduced above

• Log4j-over-slf4j: switch log4j1 to slf4j
• Slf4j-log4j12: SLf4J switches to log4j1

If these two coexist, it will inevitably lead to mutual delegation, resulting in memory overflow. However, log4j-over-slF4 makes an internal judgment to prevent memory overflow:

Namely in judge slf4j – log4j12 jar package org. Slf4j. Impl. Log4jLoggerFactory exists, if the said conflict, throw an exception prompt the user to remove the corresponding jar package, the HTML code is as follows, In slf4j – log4j12 jar package org.. Apache log4j. Log4jLoggerFactory:

At this point, the log series is finally complete. It focuses on the interaction and integration between logging systems, so delving into the architecture of individual logging systems is up to you. From: my.oschina.net/pingpangkua…