Shulou(Shulou.com)06/03 Report--

This article mainly explains "what are the reasons for the problems with the Java log?" interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what are the reasons for the problems with the Java log?"

After using the logging framework for such a long time, will you still encounter that even if you configure the log, the log is still missing?

To accept the following 8 consecutive soul torture!

Q1: have you ever encountered a situation where logback is configured and log4j error is prompted when you start up? Like this:

Log4j:WARN No appenders could be found for logger (org.example.App). Log4j:WARN Please initialize the log4j system properly. Log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

Q2: have you ever encountered this kind of error from SLF4J?

SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12 [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jarring] SLF4J: [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jarring] SLF4J Class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]

Q3: have you ever encountered abnormal printing of DUBBO logs?

Q4: have you ever encountered a situation where the Mybatis SQL log cannot be printed?

Q5: have you ever encountered a situation where the JPA/Hibernate SQL log cannot be printed?

Q6: have you ever encountered a situation in which many framework internal logs cannot be printed in complex projects?

Q7: have you ever encountered a Tomcat project where multiple copies of log files, catalina.out and other files have been printed?

Q8: have you ever encountered the problem of printing multiple copies of log files in SpringBoot projects?

What! You have also encountered various other log configuration problems.

# # conflicts in log frameworks are basically caused by the coexistence of multiple log frameworks or configuration errors. > Why is there coexistence or conflict?

Generally speaking, there are the following reasons:

The project manually references packages of various logging frameworks, such as log4j/log4j2/logback/jboss-logging/jcl, etc.

The Transitive Dependencies of package management tools leads to, for example, relying on dubbo, but dubbo depends on zkclient, but zkclient depends on log4j. If other logging frameworks exist and are used in your project, it will lead to the coexistence of multiple sets.

Coexistence of multiple versions of the same logging framework

Various logging frameworks in JAVA

Before formally introducing conflicts and resolution, you need to briefly talk about the various logging frameworks in Java:

There are two kinds of logging framework in Java, which are log abstraction / facade and log implementation.

Log abstraction / facade

Not responsible for specific log printing, such as output to files, configuration of log content format, and so on. This is just a set of log abstractions that define a unified set of log printing standards, such as Logger objects and Level objects.

The two logging frameworks, slf4j (Simple Logging Facade for Java) and jcl (Apache Commons Logging), are the most mainstream logging abstractions in JAVA.

There is also a jboss-logging, mainly for jboss series of software, such as hibernate and so on. For example, jcl has not been updated for many years (the last time it was updated was 14 years), the most recommended one is to use slf4j.

Log implementation

The mainstream log implementation frameworks in Java are as follows:

Log4j,Apache (old log framework, but has not been updated for many years, the new version is log4j2)

Log4j2,Apache (a new version of log4j, asynchronous IO has the strongest performance and simpler configuration)

Logback,QOS (slf4j is the product of this company)

Jul (java.util.logging), which is built into jdk

In the program, you can use the logging framework directly, or you can use the scheme of log abstraction + log implementation. However, it is generally implemented with log abstraction + log, which is more flexible and easier to adapt.

At present, the most mainstream solution is slf4j+logback/log4j2, but if it is a series of jboss products, more jboss-logging may be used, after all, home-made, you have to use it, right? In a framework like JPA/Hibernate, the built-in is jboss-logging.

Example of SpringBoot + Dubbo logging framework conflict

For example, the most common coexistence conflict caused by transitive dependencies: for example, if I have a "clean" spring-boot project that is so clean that there is only one spring-boot-starter dependency, I want to integrate dubbo and use zookeeper as the registry, and my dependency configuration is like this:

Org.springframework.boot spring-boot-starter org.apache.dubbo dubbo-spring-boot-starter 2.7.9 org.apache.dubbo dubbo-registry-zookeeper 2.7.9

Start the spring-boot project now and you will find a bunch of red errors:

SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12 [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jarring] SLF4J: [jar:file:/C:/Users/jiang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jarring] SLF4J Class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]-- I am the dividing line-- log4j:WARN No appenders could be found for logger (org.apache.dubbo.common.logger.LoggerFactory). Log4j:WARN Please initialize the log4j system properly. Log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

From the perspective of the error prompt, the error content is divided into two parts:

Slf4j reports an error, prompting to find the log bindings of multiple slf4j

Log4j reported an error, indicating that log4j does not have appender configuration

This error occurs because dubbo has log4j in its pass-through dependency, but the default configuration of spring-boot is slf4j+logback. After relying on dubbo-related packages, logback/jcl (apache commons-logging) / log4j/jul-to-slf4j/slf4j-log4j/log4j-to-slf4j now exists in the project.

Take a look at the dependency graph:

At this point, slf4j-log4j is the slf4j implementation of log4j, which uses log4j output when calling slf4j api, while the role of log4j-to-slf4j is to replace the implementation of log4j with log4j, which creates an endless loop.

There is also the existence of logback. Logback implements the abstraction of slf4j by default, while slf4j-log4j also implements the abstraction of slf4j.

There are two sets of slf4j implementations in the logback project, so which implementation will be used when printing using the slf4j interface?

The answer is "the first", the first Slf4j implementation class to be loaded, but this log configuration order, which relies on the ClassLoader load order, is very unreliable.

If you want to use the log normally and let all the frameworks in this project print the log properly, you must unify the log framework. However, the unity here is not forced to modify, but in the way of "adaptation / transit".

Although there is a slf4j-log4j configuration in the project, but this configuration is suitable for log4j2, and we rely on only log4j1, in fact, this transit is invalid. But logback is valid and is the default configuration of the spring-boot project, so choose logback as the unified logging framework for the project this time.

Now there is a package of log4j (1) in the project, and an error of log4j is reported at startup, indicating that some code has called log4j's api. But we don't want to use log4j, so we need to solve the log4j problem first.

Because there is a reference to the log4j code, it must not be feasible to delete log4j directly. Slf4j provides a log4j-over-slf4j package that copies a copy of log4j1's interface class (Logger, etc.) and modifies the implementation class to slf4j.

So excluding the (pass-through) dependency of log4j and referencing log4j-over-slf4j solves the log4j problem. Now let's modify the dependencies in pom (to see the dependency graph, you can use the command of maven, or the Maven Dependencies Diagram that comes with IDEA, or a plug-in such as Maven Helper).

Org.apache.dubbo dubbo-registry-zookeeper 2.7.9 compile log4j log4j org.slf4j log4j-over-slf4j 1.7.30

After solving the log4j problem, there are still two implementation problems with slf4j, which is even easier to deal with. Since we plan to use logback, we only need to eliminate / remove dependencies on the implementation of slf4j-log4j.

Org.apache.dubbo dubbo-registry-zookeeper 2.7.9 compile log4j log4j slf4j-log4j12 org.slf4j

After the modification is completed, there will be no errors when you start again, and the problem can be solved easily.

Log adaptation Daquan

Only one way of transformation is described above, but with so many logging frameworks, they can be converted to each other.

The ultimate goal is to unify a logging framework, so that there is only one set of logging implementation.

With so many log adaptations / conversions, it must be a little difficult to remember them all. Please see the following figure to match memory. If you encounter a conflict and need to convert one log framework to another, you only need to follow the path on the diagram and introduce the relevant dependency package.

For example, you want to adapt / convert slf4j to log4j2. According to the path on the diagram, you only need to reference log4j-slf4j-impl.

If you want to adapt / convert jcl to slf4j, simply delete the jcl package and reference jcl-over-slf4j.

The arrows on the picture, some marked with text, need additional packages for conversion, and some without text, are built-in adaptive implementation. In fact, the built-in implementation will be more troublesome, because if you encounter coexistence, you basically need to specify a logging implementation by configuring environment variables / configuring additional properties.

At present, slf4j is the core framework of the adaptation scheme and the central hub of this diagram. As long as you adapt / transform around slf4j, there are no conflicts that can't be dealt with.

At this point, I believe that you have a deeper understanding of "what is the cause of the problem with the Java log?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.