SLF4J 错误:类加载器具有不同的类型对象 [英] SLF4J error: class loader have different class objects for the type
问题描述
试图找出为什么我在 tomcat 日志中收到以下错误:
trying to figure out why I'm getting the following error in tomcat logs:
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature
在我的 gradle 文件中，我使用的是 slf4j 版本 1.7.7，在 tomcat 中我有 jul-to-slf4j-1.7.7.jar 和 slf4j-api-1.7.7.jar，所以我很困惑.
In my gradle files I'm using slf4j version 1.7.7, and in tomcat I have jul-to-slf4j-1.7.7.jar and slf4j-api-1.7.7.jar, so I'm pretty confused.
这是堆栈跟踪 - 感谢您的帮助！
Here is the stack trace - thanks for any help!
Total time: 2.982 secs
Using CATALINA_BASE: /usr/local/Cellar/tomcat/8.0.18/libexec
Using CATALINA_HOME: /usr/local/Cellar/tomcat/8.0.18/libexec
Using CATALINA_TMPDIR: /usr/local/Cellar/tomcat/8.0.18/libexec/temp
Using JRE_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home
Using CLASSPATH: /usr/local/Cellar/tomcat/8.0.18/libexec/bin/jul-to-slf4j-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/slf4j-api-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-classic-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-core-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-config/:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/bootstrap.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/tomcat-juli.jar
19:03:55.979 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Server version: Apache Tomcat/8.0.18
19:03:55.981 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Server built: Jan 23 2015 11:56:07 UTC
19:03:55.981 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Server number: 8.0.18.0
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - OS Name: Mac OS X
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - OS Version: 10.10
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Architecture: x86_64
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - JVM Version: 1.8.0_25-b17
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - JVM Vendor: Oracle Corporation
19:03:55.982 [main] INFO org.apache.catalina.startup.VersionLoggerListener - CATALINA_BASE: /usr/local/Cellar/tomcat/8.0.18/libexec
19:03:55.983 [main] INFO org.apache.catalina.startup.VersionLoggerListener - CATALINA_HOME: /usr/local/Cellar/tomcat/8.0.18/libexec
19:03:55.983 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Djava.util.logging.config.file=/usr/local/Cellar/tomcat/8.0.18/libexec/conf/logging.properties
19:03:55.983 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
19:03:55.983 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Djava.endorsed.dirs=/usr/local/Cellar/tomcat/8.0.18/libexec/endorsed
19:03:55.983 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Dcatalina.base=/usr/local/Cellar/tomcat/8.0.18/libexec
19:03:55.984 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Dcatalina.home=/usr/local/Cellar/tomcat/8.0.18/libexec
19:03:55.984 [main] INFO org.apache.catalina.startup.VersionLoggerListener - Command line argument: -Djava.io.tmpdir=/usr/local/Cellar/tomcat/8.0.18/libexec/temp
19:03:55.984 [main] INFO org.apache.catalina.core.AprLifecycleListener - The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /Users/jadekler/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
19:03:56.076 [main] INFO org.apache.coyote.http11.Http11NioProtocol - Initializing ProtocolHandler ["http-nio-8080"]
19:03:56.092 [main] INFO org.apache.tomcat.util.net.NioSelectorPool - Using a shared selector for servlet write/read
19:03:56.094 [main] INFO org.apache.coyote.ajp.AjpNioProtocol - Initializing ProtocolHandler ["ajp-nio-8009"]
19:03:56.096 [main] INFO org.apache.tomcat.util.net.NioSelectorPool - Using a shared selector for servlet write/read
19:03:56.096 [main] INFO org.apache.catalina.startup.Catalina - Initialization processed in 510 ms
19:03:56.115 [main] INFO org.apache.catalina.core.StandardService - Starting service Catalina
19:03:56.115 [main] INFO org.apache.catalina.core.StandardEngine - Starting Servlet Engine: Apache Tomcat/8.0.18
19:03:56.132 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application archive /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/websiteskeleton.war
19:03:56.812 [localhost-startStop-1] ERROR org.apache.catalina.core.StandardContext - Error during ServletContainerInitializer processing
javax.servlet.ServletException: Failed to instantiate WebApplicationInitializer class
at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:160) ~[spring-web-4.1.0.RELEASE.jar:4.1.0.RELEASE]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5143) ~[catalina.jar:8.0.18]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) [catalina.jar:8.0.18]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) [catalina.jar:8.0.18]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) [catalina.jar:8.0.18]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714) [catalina.jar:8.0.18]
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:917) [catalina.jar:8.0.18]
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1701) [catalina.jar:8.0.18]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_25]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:306) ~[slf4j-api-1.7.7.jar:1.7.7]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276) ~[slf4j-api-1.7.7.jar:1.7.7]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) ~[slf4j-api-1.7.7.jar:1.7.7]
at com.websiteskeleton.core.HelloInitializer.<init>(HelloInitializer.java:13) ~[HelloInitializer.class:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_25]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_25]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_25]
at java.lang.reflect.Constructor.newInstance(Constructor.java:408) ~[na:1.8.0_25]
at java.lang.Class.newInstance(Class.java:438) ~[na:1.8.0_25]
at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:157) ~[spring-web-4.1.0.RELEASE.jar:4.1.0.RELEASE]
... 12 common frames omitted
19:03:56.821 [localhost-startStop-1] ERROR org.apache.catalina.core.StandardContext - Context [/websiteskeleton] startup failed due to previous errors
19:03:56.825 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application archive /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/websiteskeleton.war has finished in 693 ms
19:03:56.826 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/docs
19:03:56.893 [localhost-startStop-1] INFO org.apache.jasper.servlet.TldScanner - At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
19:03:56.904 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/docs has finished in 78 ms
19:03:56.904 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/examples
19:03:57.133 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/examples has finished in 228 ms
19:03:57.133 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/host-manager
19:03:57.192 [localhost-startStop-1] INFO org.apache.jasper.servlet.TldScanner - At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
19:03:57.195 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/host-manager has finished in 62 ms
19:03:57.195 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/manager
19:03:57.252 [localhost-startStop-1] INFO org.apache.jasper.servlet.TldScanner - At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
19:03:57.254 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/manager has finished in 59 ms
19:03:57.254 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deploying web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/ROOT
19:03:57.307 [localhost-startStop-1] INFO org.apache.jasper.servlet.TldScanner - At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
19:03:57.308 [localhost-startStop-1] INFO org.apache.catalina.startup.HostConfig - Deployment of web application directory /usr/local/Cellar/tomcat/8.0.18/libexec/webapps/ROOT has finished in 54 ms
19:03:57.310 [main] INFO org.apache.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8080"]
19:03:57.314 [main] INFO org.apache.coyote.ajp.AjpNioProtocol - Starting ProtocolHandler ["ajp-nio-8009"]
19:03:57.315 [main] INFO org.apache.catalina.startup.Catalina - Server startup in 1218 ms
推荐答案
Tomcat 日志显示您在类路径上还有另一个 slf4j-1.7.7.jar:
The Tomcat log shows you have another slf4j-1.7.7.jar on the classpath:
使用类路径:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/jul-to-slf4j-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/slf4j-api-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-classic-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-core-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-config/:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/bootstrap.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/tomcat-juli.jar
Using CLASSPATH: /usr/local/Cellar/tomcat/8.0.18/libexec/bin/jul-to-slf4j-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/slf4j-api-1.7.7.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-classic-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-core-1.1.2.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/logback-config/:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/bootstrap.jar:/usr/local/Cellar/tomcat/8.0.18/libexec/bin/tomcat-juli.jar
Tomcat 初始化时，会初始化 jul-to-slf4j 和 slf4j-api.这些 jar 由加载 Tomcat jar (sun/misc/Launcher$AppClassLoader) 的 Classloader 加载.
When Tomcat is been initialized, it initialize jul-to-slf4j and slf4j-api. These jars are been loading by the Classloader which loaded the Tomcat jars (sun/misc/Launcher$AppClassLoader).
当您的应用程序尝试访问 slf4j-api 类时，它使用 WebApplication Classloader (org/apache/catalina/loader/WebappClassLoader)，默认情况下，它会在系统类路径之前在应用程序类路径上搜索类定义.请注意，这可以更改:https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
When your application tries to access the slf4j-api classes, it uses the WebApplication Classloader (org/apache/catalina/loader/WebappClassLoader), which by default search for classes definition on the app classpath before the system classpath. Note this can be changed: https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
在 Java 中，类签名由类的全限定名和加载类的类加载器组成.如果一个类从两个不同的类加载器(相同的层次结构)加载两次，则 JVM 将有两个不同的类.试图将一个类的对象引用指向另一个类的变量将引发 ClassCastException.查看此博客文章(第 5 项)了解更多信息:https://techblug.wordpress.com/2012/03/17/classloader-tips/
In Java, the class signature is composed of the class full qualified name and the classloader that loaded the class. If a class is loaded two times from two different classloaders (same hierarchy), there will be two different classes for the JVM. Trying to point a object reference of one class to a variable of the other will trhow a ClassCastException. Check this blog post (item 5) for more info on this: https://techblug.wordpress.com/2012/03/17/classloader-tips/
因此，据我所知，您可以通过从 Tomcat 类路径中删除 slf4j-*.jar 来解决此问题，或者如果您有多个使用相同版本 slf4j 的 web 应用程序，您可以从webapp，所以它将使用Tomcat类加载器加载的那些.
So, as far as I know, you can fix this by removing the slf4j-*.jar from the Tomcat classpath, or if you have more then one webapp using the same version of slf4j, you can remove the jars from the webapp, so it will use those loaded by Tomcat classloader.
这篇关于SLF4J 错误:类加载器具有不同的类型对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
