Note: This article is reprinted toJava logging system overview, invasion delete ~
1 introduction
This paper mainly explores the following contents:
- This section describes the development history of the Java logging system
- Slf4j logging facade is introduced, and the relationship and dependence between existing logging systems are sorted out
2. Development history of log system
Commons-logging.jar, log4j.jar, slf4j-api.jar, logback.jar, etc. To clarify their relationship, we need to start with the history of Java Log.
1.log4j
Log4j (by Ceki Gulcu) became widely used when it came out as the de facto standard for Java logging and became an Apache project.
2.JUL
Log4j As a member of the Apache Foundation, Apache wanted to introduce log4j into the JDK, but Sun refused. Sun then mimicked log4j and implemented JUL, java.util.logging, in jdk1.4.
3.JCL
JUL, after all, comes with the JDK and is widely used. There are other log components, such as SimpleLog. At this point, if someone wants to switch to another logging component, such as Log4j to JUL, because the API is completely different, they need to change the code.
To decouple the Logging interface from the implementation, Apache has introduced JCL, Apache Commons Logging. JCL defines only a set of logging interfaces, implemented by Log4J or JUL. JCL implements logging based on dynamic binding, and you only need to write code using the jCL-defined interface. When the program actually runs, it checks the implementation in the CLASspath, so you can choose whether log4J or JUL implements logging.
4.slf4j&logback
This is all very well, but the author of Log4j (Ceki Gulcu) decided that JCL was not working and developed SLF4J, which, like JCL, does not implement logging itself, but only provides an interface or facade. The goal is to replace JCL. At the same time, LogBack, a component with higher performance than Log4J, was developed to replace log4J.
5.log4j2
Finally, Apache, in order to prevent SLF4J and Logback from slowly replacing JCL and Log4J, has come up with its own counterattack, Log4J2, which offers a significant performance improvement over Log4J. As a result, we see so many logging frameworks coexist.
Note: Log4j2 is by far the best logging framework in Java.
3 Relationships/dependencies
After understanding the development course roughly, look at the relationship between them in detail again, depend on.
3.1 the JCL
Commons-logging has stopped updating and the last state is as follows:
JCL supports a limited number of logging components, and fewer and fewer people are using them.
3.2 SLF4J Bridges to a specific logging framework
The image below is from the official documentation:
As you can see from the figure above, SLF4J can use almost any specific logging framework.
The above picture is interpreted as follows:
- Green application: Application layer, down to the API provided by SLF4J
- Abstract Logging API in light blue: Abstract API layer
- Slf4j-api native implementation of slF4J-API: slF4J-API native implementation of SLF4J-API
- They’re a layer of adaptation that allows them to build Bridges
- Non-native implementation of SLF4J-API: specific logging framework implementation layer, itself does not implement SLF4J-API, need a bridge
At the third level, all the gray JARS have red boxes, which means that they implement SLf4J-API directly, except that the lake blue bridge does not directly export logging to slf4J-API, but instead goes to call the API declared by another logging framework.
Slf4j – simple. Jar and slf4j – nop. Jar both needless to say, the name will know that a simple implementation is slf4j, one is empty implementations of slf4j, use at ordinary times also is not big. Slf4j-api is implemented in Logback because the same person wrote logback and SLf4J.
3.3 Specific logging framework is bridged to SLF4J
In addition to the Bridges from SLF4J to other logging frameworks, there is another class of Bridges that do the exact opposite and can transfer apis from other logging frameworks to SLF4J’s apis.
The image below is from the official documentation:
The figure above shows three cases where you can safely call back to SLF4J from another logging framework API. The way to do this is to replace the logging framework JAR with a specific bridge JAR as shown in the figure.
Take the first case in the upper left: when the concrete implementation used by SLF4J at the bottom is LogBack, the logging framework apis at the top that allow bridging to SLF4J are Log4J and JUL. JCL is not an implementation of a logging framework, but its API can still be rolled back to SLF4J.
After looking at all three cases, you’ll see that almost all the apis of other logging frameworks, including the JCL API, can be rolled back to SLF4J at will. One limitation, however, is that the logging framework referred back to SLF4J cannot be the same as the specific logging implementation framework currently used by SLF4J. This restriction prevents both a-to-B.jar and b-to-a.jar from appearing in the classpath at the same time, resulting in A and B constantly recursing to each other and eventually causing stack overflows.
For example, assume that the logging framework uses SLF4J + Log4j. A specific log operation process is as follows:
Slf4j’s API interface is called first, and slF4J forwards the request to SLF4J-log4j12 for processing, which is statically bound at compile time. Finally, SLf4J-log4j12 uses log4j to perform logging operations. What if log4J-over-slf4j was added to the project? As shown below, the logging request is redirected back to SLF4J, forming a ring.
4 Reference Reading
- Summary of Java logging architecture
- Java logging system overview
- Program to the Log4J2 API instead of SLF4J