Java Log System

1, a small story

Let's read a story first. Project manager A with a bunch of brothers to develop a complex enterprise ERP system, the system has been developed for several years, developers have also changed several dials.

Phase one: At the very beginning, project manager a arranges small B to add log functions to the system and print some necessary information on the console. At first, because the project is less functional, so small B is to use the System.out.println way to print the log information. Manager A feels that this is easier to use and easier for the project team to use, so it is used.

Stage two: At this time small B was seconded to other projects, and small C was added to the project team. At this point, project manager a requirements for the transformation of the log system, the request can be written to a file, to facilitate later analysis of user behavior. Small c After looking at the previous log mode, feel particularly low, so he wrote a log framework, named Xiaoc-logging.jar, the move received project manager A's praise.

Stage Three: The project team added a big Daniel old D, old D found Xiaoc-logging.jar This log framework can meet the basic log requirements, but is not large enough, not some such as automatic archiving, writing files asynchronously, write log files to the NoSQL database medium function. Thereupon the old D developed a more advanced log framework called Oldd-logging.jar.

Phase four: After the development of Oldd-logging.jar, we need to change the log API in the original Xiaoc-logging.jar, write down the previous log implementation, and put on the tall Oldd-logging.jar.

Phase five: In this uninstall and the new process, the old D workload, he felt very tired. But Ginger is still old spicy, he referred to the JDBC and spring in the interface-oriented programming, developed a log of the façade (a series of interfaces), after all the log records, are only interface-oriented programming, as for the future how to achieve, all to follow this interface can be.

2. The evolution of the Java log system

So how does this log system evolve in Java development? Briefly describing the next log development, the first to emerge is the Apache open source community's log4j, which is indeed the most widely used logging tool, becoming the de facto standard for Java logs. However, at that time, sun Company in jdk1.4 added the Jul log implementation, attempts to fight against log4j, but caused confusion, this is also a point of criticism. Of course, there are other log tools, which will inevitably cause confusion for developers, because these log systems are not related to each other, replacement and unification has become a more difficult thing. Imagine your app using log4j, and then using a library of other teams, they use Jul, your app has to use two log systems, and then a second library appears, using Simplelog. It's time to let you down. This situation to you to think of ways, how can you solve it? Abstraction, an interface layer is abstracted, and each log implementation is adapted or transferred so that the libraries provided to others use the abstraction layer directly. Yes, the open source community provides the commons-logging abstraction, called the JCL, that is, the log framework, is really excellent to achieve a compatible mainstream log implementation (LOG4J, JUL, Simplelog), the basic unified lakes and rivers, Even the top name of spring is dependent on the JCL. It seems that things are really good, but the good days are not long, and then another good log frame slf4j The addition of a more chaotic scene. The more ingenious is the author of the SLF4J (Ceki gülcü) is the author of Log4j, he felt that JCL is not good enough, so he wants to make a more elegant out, so slf4j log system was born, and for SLF4J to achieve a parent-child--logback, Really more elegant, but because many code base already used JCL, although the slf4j and JCL between the bridge conversion, but the integration of the problem is still a lot of, for many novice will be very annoyed, because more than the individual log4j era "complex" more, complaining sound really many. To this should be finished, but Ceki gülcü think still have to go back to save their "big elder brother"--log4j, so log4j2 birth, the same log4j2 also participate in the SLF4J log system, presumably in the future will be more chaotic. Next, we explain the problem of the use of the log system. SLF4J design is indeed more elegant, using a more familiar way-interface and implementation of separation, there is a pure interface layer--SLF4J-API Engineering, which basically completely defines the interface of the log, so for development, only need to use this. There will be an interface to achieve, the more respected implementation is Logback,logbaCK fully realizes the interface of Slf4j-api, and the performance is better than log4j, and realizes the new features such as the output mode of the variable parameter placeholder log. Just also mentioned that the use of log4j is more common, so support this batch of users is still necessary, SLF4J-LOG4J12 also realized the SLF4J-API, this is considered to log4j adapter. Same reasoning, there will be the adapter slf4j-jdk14 to Jul and so on. In order to make use of the JCL and other log system the latter implementation of the user can be very simple to switch to slf4j up, give a variety of bridge engineering, such as: JCL-OVER-SLF4J will be the call to the JCL Bridge to slf4j up, It can be seen that the JCL-OVER-SLF4J API and JCL are the same, so the two jars cannot coexist. JUL-TO-SLF4J is the call to Jul on the bridge to SLF4J, LOG4J-OVER-SLF4J is to log4j the call Bridge to SLF4J.

We need to choose a façade (abstraction layer) on the left and the right side to choose an implementation. So the best choice is

Log façade: slf4j, log implementation: Logback.

The bottom of the springboot is the spring framework, and the spring framework defaults to JCL. But Springboot chooses slf4j and logback;

3,slf4j use principle rules

We go to SLF4J's official website and open the user manual to see simple usage cases:

Import Org.slf4j.logger;import Org.slf4j.loggerfactory;public class HelloWorld {public  static void Main (string[] args) {    Logger Logger = Loggerfactory.getlogger (helloworld.class);    Logger.info ("Hello World");}  }

　　

Of course, before using, you need to import slf4j jar and logback implementation jar, but if it is to do other log implementation, which need to rely on the jar package, the official website provides us with a graph:

Let's take a look at this diagram, where each of these columns is about how to integrate the SLF4J (log façade) with the implementation of other logs. Where light blue represents the abstract log API, that is, we say the log façade (Slf4j-api.jar), dark blue is the specific log implementation, Cyan represents a log adapter, gray representation and SLF4J no directly associated log implementations.

The first column: The log façade uses Slf4j-api.jar, but without any log implementations, the log will not output anything.

The second column is about how slf4j and Logback bind. Log façade is using Slf4j-api.jar, then the implementation of the log uses Logback-classic.jar and Logback-core.jar. As we have said before, Logback is Slf4j's son, so slf4j can connect seamlessly with Logback.

The third column: said SLF4J and log4j how to bind, we know slf4j and log4j author is the same person, but as an excuse to appear slf4j than log4j, so slf4j and log4j can not seamlessly connect, An adaptation layer Slf4j-log4j12.jar is required. The adapter then implements the interfaces and abstract classes in the Slf4j-api.jar, but is implemented or used by the Log4j API. This solves the problem of integration of LOG4 and SLF4J.

Fourth column: slf4j and Jul (java.util.logging) How to bind, the principle and the third column.

The fifth column: SLF4J itself provides a simple implementation called Slf4j-simple.jar. The two can be seamlessly connected.

Column Sixth: SLF4J itself provides a slf4j-nop.jar that does not have any implementation. This log does not have any operations and does not output logs.

If you understand this diagram, you will know the dependencies of which jar files need to be imported. The implementation framework for each log has its own configuration file. But in the future log system, so many log implementations, what kind of log configuration file should be used, we have a principle is: after using SLF4J, the configuration file is made into a log implementation framework of its own configuration file.

4, other log frame unified conversion to SLF4J

Recall that when we do the SSM framework integration, spring and SPRINGMVC use JCL (Jarkart commons-logging), mybatis using the log4j log framework, it is possible that other jar files depend on the JCL (Java Util logging), then how to convert these different log frames into a log of the agreed SLF4J, the official website provides us with a diagram:

First Block:

Said is a system, if used SLF4J as a unified log façade, and use logback do log implementation, but at this time there are commons-logging, log4j, Jul and other log implementation how to do? At this time need to replace the commons-logging with Jcl-over-slfj.jar, with Log4j-over-slf4j.jar instead of Log4j.jar, and add Jul-to-slf4j.jar (cannot replace Jul, because this is the JDK comes with)

Second BLOCK:

Said is a system, if used SLF4J as a unified log façade, and use log4j do log implementation, but at this time there are commons-logging, Jul and other log implementation how to do? In this case, you need to replace commons-logging with Jcl-over-slfj.jar, and add Jul-to-slf4j.jar (you cannot replace Jul because it comes with the JDK), and add slf4j and log4j adaptation layers Slf4j-log4j12.jar as well as real The present layer Log4j.jar.

Third BLOCK:

Said is a system, if used SLF4J as a unified log façade, and use Jul to do the implementation of the log, but at this time there are commons-logging, log4j and other log implementation how to do? At this time need to replace the commons-logging with Jcl-over-slfj.jar, with Log4j-over-slf4j.jar instead of Log4j.jar, and add Slf-jdk14.jar as an adaptation layer, and finally, with the JDK's own Jul as the implementation of the log.

Summary: How to make all the logs in the system unified to SLF4J;

1, the system of other log frame first excluded;

2. Replace the original log frame with the intermediate package (based on);

3, we import slf4j other implementation

Java Log System