Problem Description:

When Tomcat fails to start, the following error log is displayed in Catalina. out:

INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log Closing Spring root WebApplicationContext SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStop Exception sending context destroyed  event to listener instance of class org.springframework.web.context.ContextLoaderListener java.lang.NoClassDefFoundError: Could not initialize class org.apache.log4j.Log4jLoggerFactory at org.apache.log4j.LogManager.getLogger(LogManager.java:44) at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:156) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:274) at org.springframework.web.context.ContextCleanupListener.<clinit>(ContextCleanupListener.java:43) at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:145) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4860) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5495) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:224) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:159) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1407) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1397) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)Copy the code

 

Problem analysis:

Log4j and logback have been updated to the lib library.

Jar slf4j-api-1.7.5.jar slf4j-log4j-1.2.16. jar log4j-over-slf4j-1.7.5.jar logback-core-1.1.2.jar slf4j-api-1.7.5.jar slf4j-1.6.jar Logback - classic - 1.1.2. JarCopy the code

The package slf4J-log4j12-1.6.1. jar conflicts with log4j.

 

 

Solutions:

Slf4j-log4j12-1.6.1.jar: slf4j-log4j12-1.6.1.jar

 

Common combination of accessories:

Jar slf4j- log4j-1.6.1. jar slf4j- log4j12-1.2.16. jar slf4j+logback logback-core-1.1.2.jar Logback - classic - 1.1.2. Jar slf4j - API - 1.7.5. JarCopy the code

 

Today I have time to share with you: First of all, there was no such problem in the test environment and online simulation environment of P version. In the official version, the stack result given by operation and maintenance personnel is as follows:

view plaincopy to clipboardprint?

[19:56:18. 083] under Caused by: Java. Lang. NoClassDefFoundError: Could not initialize class org. Apache. Log4j. Log4jLoggerFactory at [19:56:18. 083] Org, apache log4j. Logger. GetLogger (Logger. Java: 39) at [19:56:18. 083] Com. Focustech. Redis. Util. JsonUtil. < clinit > (JsonUtil. Java: 22) at [19:56:18. 083] Sun. Reflect. NativeConstructorAccessorImpl. NewInstance0 (Native Method) at [19:56:18. 083] Sun. Reflect. NativeConstructorAccessorImpl. NewInstance (NativeConstructorAccessorImpl. Java: 39) at [19:56:18. 083] Sun. Reflect. DelegatingConstructorAccessorImpl. NewInstance (DelegatingConstructorAccessorImpl. Java: 27) at [19:56:18. 083] Java. Lang. Reflect. Constructor. NewInstance (513) Constructor. Java: [19:56:18. 083] the at Org. Springframework. Beans. BeanUtils. InstantiateClass (BeanUtils. Java: 82) at [19:56:18. 083] Org. Springframework. Beans. BeanUtils. InstantiateClass (BeanUtils. Java: 59) at [19:56:18. 083] org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:52) At [19:56:18. 083] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBean Factory. Java: 639) at [19:56:18. 083] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableB EanFactory. Java: 625) at [19:56:18. 083] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFacto Ry. Java: 380) [19:56:18. 083]... 21 moreCopy the code

 

For such error stack, we first checked whether the JAR package was missing, but found that in fact the JAR package exists, and the class also exists, so we continued to check whether the problem is caused by the jar package conflict, and found that the application poM file only has one such class related to this class, there are not many. So again sent jar package conflict problem, so temporary log modification, but the result is still reported such error. It was at this point that I tried to look up other information in the log and found such an error stack in the container’s System error file

view plaincopy to clipboardprint?

  1. SLF4J: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflowError.   
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.  
Copy the code

     

This time we found that may be the two jars make of ghost, so I’m under the baidu, do the two jars will quote such a mistake Specific reason analysis of the article is very good, can learn under www.tuicool.com/articles/IN… The runtime error file is the container’s error file, and the runtime error file is the container’s error file. The runtime error file is the container’s error file.

 

Possible exceptions:

 

The logback.xml file did not work, so we analyzed the startup log and found SLF4J conflict exception in the log:

  1. SLF4J: Class path contains multiple SLF4J bindings.
  2. SLF4J: Failed to load the class “org. SLF4J. Impl. StaticLoggerBinder”

Cause analysis:

Since it is a conflict, it is possible that the project relies on several different versions of slf4J class libraries. How to analyze which libraries depend on SLF4J? We can use the dependency:tree command:

$ mvn dependency:tree
Copy the code

Solution:

After the dependency tree analysis, it was found that Zookeeper and Dubbo libraries reference slF4J libraries respectively, so

was used to exclude transitive dependencies.

Alibaba </groupId> <artifactId>dubbo</artifactId> <version>2.8.4</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> < the dependency > < groupId > org. Apache. Zookeeper < / groupId > < artifactId > zookeeper < / artifactId > < version > 3.4.6 < / version > <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency>Copy the code

Various other dependency conflicts can be resolved in this way.