The profile

The purpose of this paper is to clear up all the Java Log is how the relationship between the Log, how to effect, dependence, so we usually work in if you encounter “Log out” or “Log jars conflict issues such as” know how to start to solve, and how to adjust the project under various scenarios of each frame of the Log output, make the output.

Log System

Jar, log4j.jar, sl4j-api.jar, logback.jar, and so on. We need to properly configure jar packages to interact with each other before they can be understood.

Background/Development History

Let’s start with the history of Java Log.

1. Log4j (by Ceki Gulcu) came out to be widely used (note the direct use here), the de facto standard for Java logging, and an Apache project

Apache requested that log4j be incorporated into the JDK. SUN refused and added JUL (java.util.logging) after JDK 1.4.

3. After all, it comes with the JDK, and JUL 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.

Apache developed JCL (Jakarta Commons Logging), also known as commons-logging-xx.jar. It only provides a set of generic logging interface apis and does not provide an implementation of logging. It’s a good design principle to rely on abstraction rather than implementation. This allows the application to choose the logging implementation component it wants at run time.

5. This is all very well, but the authors of Log4j felt that JCL was not working and developed SLF4J themselves, which, like JCL, does not implement logging itself, but 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.

Apache took a look at LogBack and made a series of optimizations to launch log4j2

Relationship/dependency

After understanding the process of the mind, look at the relationship and dependence between them in detail.

JCL

Commons-logging has stopped updating and the last state is as follows:JCL does not support many logging components, but there are some popular ones, such as Spring, which now uses less and less, and SLF4J

At that time, Java logging components were quite chaotic and complex. After Ceki Gulcu introduced SLF4J, slF4J adaptation diagrams were also introduced for various mainstream logging components in the industry, which came from official documents

If you want to use SLF4J as a logging facade, how you can use other logging implementation components is illustrated here.

slf4j + logbackslf4j-api.jar + logback-classic.jar + logback-core.jar

slf4j + log4jslf4j-api.jar + slf4j-log4j12.jar + log4j.jar

slf4j + julslf4j-api.jar + slf4j-jdk14.jar

It is also possible to implement slf4J-api.jar + slf4j-nop.jar using only SLf4j without logging

Adaptation of SLF4J

Slf4j supports a variety of adaptations, and regardless of which logging component you are currently using, you can use slF4J through the slF4J adapter. As soon as you switch to SLF4J, then implement the components using SLF4J, as described above. Figure is from official documentationIn fact, in general, no matter is the following cases

You are using JCL using jCL-over-slf4j.jar adaptation

You are using log4j using log4J-over-slf4j.jar adaptation

You are using JUL using jul-to-slf4j.jar adaptation

I stole a map on the Internet to give you an overall dependency map (too lazy to draw)Let Spring unify the output

This is to do an example of slF4J adaptation. Slf4j + logback = slf4J + logback = slf4J + logback The advantage of this is that we can unify the log output (log format, log file, storage path, etc., and other functions supported by SLF4J) of other modules and frameworks within the project. It is easy to add jCL-over-slf4j.jar. I stole another diagram to illustrate it

Adaptive thinking

It’s actually quite simple

You first identify which logging component is used by the module, framework, and sFL4J adapter that requires unified logging.

Remember to remove useless logging implementation components and keep only the ones you need.

Q&A

Slf4j’s log loading will print the log when the program starts, so be sure to note that it will indicate whether or not the log implementation was successfully loaded. Slf4j has addressed the error. Here are some common problems you may encounter

Failed to load class org.slf4j.impl.StaticLoggerBinder

No logging implementation found, if you think you have written the corresponding logging implementation dependency, then you need to check, generally there is a high probability of version incompatibility. Multiple Bindings find Multiple logging implementations, and SLF4J will find one as the logging implementation.

Code specification

Ali’s code specification for this:

[Mandatory] Applications must rely on the API of SLF4J rather than the API of logging system (Log4j and Logback). Using the facade logging framework helps maintain and unify the log processing modes of each class. import org.slf4j.Logger; import org.slf4j.LoggerFactory; private static final Logger logger = LoggerFactory.getLogger(Abc.class);

conclusion

This article helps you sort out the relationship between Java logging components, and how to solve the daily common log related problems, I hope to help you.