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 that it was used directly), the de facto standard for Java logging, and became an Apache project

2.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 nice, but the authors of Log4j felt that JCL was not working and developed SLF4J themselves, which is similar to JCL in that it 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.

6.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 also popular ones, such as Spring, which is now used less and less, and not much to talk about

SLF4J

At that time, Java logging components were chaotic and complex. After Ceki Gulcu introduced SLF4J, slF4J adaption was also introduced for various mainstream logging components in the industry

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

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

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

3.slf4j + jul slf4j-api.jar + slf4j-jdk14.jar

4. You can also 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.

In fact, in general, regardless of the following situations:

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

2. If you are using log4j, use log4J-over-slf4j.jar to adapt

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

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 is quite simple. You first identify which logging component is used by the module and framework that requires unified logging, and then find the adapter for SFL4J. 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 (www.slf4j.org/codes.html). 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 cannot use the API of logging system (Log4j and Logback) directly, but should rely on the API of logging framework SLF4J. Using the log framework in facade mode helps maintain and unify the log processing mode 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.

I have arranged a: Java systematic information: (including Spring series family barrel, Java core knowledge, interview topics and the latest Internet real questions in 20 years, e-books, etc.) friends who need to pay attention to the public number can be obtained.