Log4j giving ClassCastException about slf4j LoggerContext - java

I have configured log4j in my Java application and I am getting this
exception : java.lang.ClassCastException:
org.apache.logging.slf4j.SLF4JLoggerContext cannot be cast to
org.apache.logging.log4j.core.LoggerContext.
I already tried after remove log4j-slf4j-impl-2.2.jar and log4j-to-slf4j-2.2.jar but It didn't work it out.

Try this (is the 'standard' way to use a logger):
In your class:
private final static Logger logger = LoggerFactory.getLogger(YourClass.class);
In your methods:
if(logger.isInfoEnabled()) {
logger.info("your log message");
}
And the maven dependencies (pom.xml):
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.12</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>

You can solve this error by following steps:
Include slf4j-api.jar,log4j-api.jar,slf4j-log4j.jar
and
Use logger of slf4j.

Related

How do I fix "SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder"."

I have an application that has the following error message:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
This message occurs after I attempt to run any script for the application. I have found that, as it says, it does not create logs, so I have come up empty handed when something fails.
I am running this in Amazon Linux 2 which is closest to CentOS and Redhat.
I have found the following resources:
This issue is addressed here: http://www.slf4j.org/codes.html#StaticLoggerBinder
I can get the jar I need from here: https://repo1.maven.org/maven2/org/slf4j/slf4j-simple/1.6.2/slf4j-simple-1.6.2.jar
After taking this jar and dropping it into my application's /lib, nothing changes.
Other articles describe adding this file to the class path. In Linux, I get this:
# java -classpath /opt/opendj/lib/slf4j-simple-1.6.2.jar org.slf4j.impl.StaticLoggerBinder
Error: Could not find or load main class org.slf4j.impl.StaticLoggerBinder
# java -jar /opt/opendj/lib/slf4j-simple-1.6.2.jar org.slf4j.impl.StaticLoggerBinder
no main manifest attribute, in /opt/opendj/lib/slf4j-simple-1.6.2.jar
Am I trying to add it to the class path right?
If needed, you can reproduce this issue by doing the following:
Steps to reproduce the behavior:
Install a fresh version of OpenDJ onto CentOS or Amazon Linux2 EC2 Instance. Install java 1.8.0
specifically java-1.8.0-openjdk
Install the server in any configuration, then run a status script.
Expected behavior
Logs should generate and no warning message can be presented.
Firstly, you should take a look here : https://www.slf4j.org/codes.html
Also,you can try adding these SLF4J maven dependencies into your pom and let me know if this works:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.13.3</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.13.3</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.13.3</version>
</dependency>
Note: Consider that the maven dependencies versions are being updated, then maybe you prefer use the lates version of the dependencies(for example for log4j-api is 2.17.0)
On the other hand, this post could help you as well:
https://mkyong.com/java/log4j2-failed-to-load-class-org-slf4j-impl-staticloggerbinder/
In my case I was getting this error while using MavenCli lib. I had missed to add maven-compat lib in pom.xml. Below is full sample code I had used.
Sample code :
MavenCli mavenCli=new MavenCli();
mavenCli.doMain(new String[]{"clean","install"}, path_of_project_dir, System.out, System.out);
Dependency required :
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>3.6.3</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.30</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-compat</artifactId>
<version>3.6.3</version>
</dependency>
In my case, I was using the logback in a spring-boot app and faced this issue. It was related to incompatible versions of slf4j and logback which were coming from third party libraries. I excluded all of them and used these:
<!-- logging dependencies-->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
${logback.version} and ${slf4j.version} are coming from spring-boot-dependencies-2.X.X.pom file.
I hope it will help :)
<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.6</version>
</dependency>
<!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-classic -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.4.5</version>
</dependency>

java.lang.AbstractMethodError: on Jersey Rest Webservice call after upgrading Weblogic to 12c (12.1.3.0.0)

A part of our application which calls a REST webservice using Jersey Client 2.15 stopped working after we upgraded our Weblogic to Weblogic 12C - 12.1.3.0.0.
The exception trace we were getting was:
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)
at org.glassfish.jersey.client.JerseyWebTarget.<init>(JerseyWebTarget.java:71)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:185)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:70)
We were sure that it was a javax.ws.rs mismatch between Jersey and Weblogic WS libraries.
Dependencies
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.15</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>2.15</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.connectors</groupId>
<artifactId>jersey-apache-connector</artifactId>
<version>2.15</version>
</dependency>
Not longer did we realize that following our application logs with the above stack trace was misleading. So we started looking into Weblogic logs. The domain log did in fact gave as a totally different stack trace:
java.lang.NoSuchMethodError: org.glassfish.hk2.api.ServiceLocatorFactory.create(Ljava/lang/String;Lorg/glassfish/hk2/api/ServiceLocator;Lorg/glassfish/hk2/extension/ServiceLocatorGenerator;Lorg/glassfish/hk2/api/ServiceLocatorFactory$CreatePolicy;)Lorg/glassfish/hk2/api/ServiceLocator;
at org.glassfish.jersey.internal.inject.Injections._createLocator(Injections.java:138)
at org.glassfish.jersey.internal.inject.Injections.createLocator(Injections.java:109)
at org.glassfish.jersey.internal.RuntimeDelegateImpl.<init>(RuntimeDelegateImpl.java:63)
at
So after some firefighting and playing around with weblogic.xml and package overrides the issue was sorted. The following were the final package overrides which actually did solve the problem:
<wls:package-name>com.sun.jersey.*</wls:package-name>
<wls:package-name>org.glassfish.jersey.*</wls:package-name>
<wls:package-name>org.glassfish.hk2.*</wls:package-name>
<wls:package-name>org.jvnet.hk2.*</wls:package-name>
<wls:package-name>jersey.repackaged.org.objectweb.asm.*</wls:package-name>
<wls:package-name>org.objectweb.asm.*</wls:package-name>
<wls:package-name>com.sun.ws.rs.ext.*</wls:package-name>
<wls:package-name>javax.ws.rs.*</wls:package-name>

[JAVA Spring SOAP WSDL]

I try to connect to a Web Service using spring/soap/wsdl. I'm receiving a stack trace like this:
Exception in thread "main" org.springframework.ws.soap.SoapMessageCreationException: Could not create message from InputStream: Unable to create envelope from given source: ; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:216)
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:60)
at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:92)
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:608)
at org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive(WebServiceTemplate.java:555)
at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:390)
at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:383)
at com.arek.soapallegrotest.WsSearchClient.doLogin(WsSearchClient.java:60)
at com.arek.soapallegrotest.WsSearchClient.doSearchResponse(WsSearchClient.java:81)
at com.arek.soapallegrotest.SpringMain.main(SpringMain.java:24)
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:
at com.sun.xml.internal.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:117)
at com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeFromSource(SOAPPart1_1Impl.java:69)
at com.sun.xml.internal.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:128)
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:189)
... 9 more
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source because the root element is not named "Envelope"
at com.sun.xml.internal.messaging.saaj.soap.SOAPPartImpl.lookForEnvelope(SOAPPartImpl.java:154)
at com.sun.xml.internal.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:121)
at com.sun.xml.internal.messaging.saaj.soap.EnvelopeFactory.createEnvelope(Envel
opeFactory.java:110)
... 12 more
2015-03-30 16:30:26.747 INFO 12079 --- [ Thread-1] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext#3cb1ffe6: startup date [Mon Mar 30 16:30:24 CEST 2015]; root of context hierarchy
I've used this tutorial: https://spring.io/guides/gs/consuming-web-service/#initial to learn my self.
I found some info that I have something wrong with namespace ?
ps. sorry for my english
I had same problem and the cause was in line like this:
WebServiceTemplate template = new WebServiceTemplate(messageFactory());
...
template.setDefaultUri("http://host:2121/portal/service?wsdl");
solution was to remove ?wsdl
I had the same problem. I don't know exactly what is causing this in your sources because you didn't add any specific informatcion, but I can tell it began giving this error in my project when I added fop to my pom:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>fop</artifactId>
<version>1.1</version>
<!-- some exclusions needed because of inexistent "avalon" packages in maven repositories -->
</dependency>
It did happen with every version of fop I could find through maven.
I found a solution here. Apparently, the xalan and xerces included in fop needed to be upgraded.
I'm not happy with this solution, but it works. I left some exclusions I'm not sure are needed or could damage something else because a deadline is coming very fast (ha ha ha). I'll get into it later (or hope someone else can comment about them).
Here I add my pom fragment:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>fop</artifactId>
<version>1.1</version>
<exclusions>
<!--
Following avalon-framework versions that come
as dependencies for fop 1.1 are not found
through maven:
See: https://issues.apache.org/jira/browse/FOP-2151
-->
<exclusion>
<groupId>org.apache.avalon.framework</groupId>
<artifactId>avalon-framework-api</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.avalon.framework</groupId>
<artifactId>avalon-framework-impl</artifactId>
</exclusion>
<!--
Without following exclusions I get the following
exception when trying to access another web service:
2015-04-24 13:48:25,048 ERROR [http-nio-8084-exec-2] (CfdiController.java:152) -
Error while uploading. org.springframework.ws.soap.SoapMessageCreationException:
Could not create message from InputStream: Unable to create envelope from given
source: ; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl:
Unable to create envelope from given source:
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:216)
~[spring-ws-core-2.2.0.RELEASE.jar:2.2.0.RELEASE]
See: https://stackoverflow.com/a/13156775/2796922
-->
<exclusion>
<artifactId>maven-cobertura-plugin</artifactId>
<groupId>maven-plugins</groupId>
</exclusion>
<exclusion>
<artifactId>maven-findbugs-plugin</artifactId>
<groupId>maven-plugins</groupId>
</exclusion>
<exclusion>
<artifactId>xalan</artifactId>
<groupId>xalan</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
</exclusions>
</dependency>
<!--
These avalon dependencies are found in maven:
-->
<dependency>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework-api</artifactId>
<version>4.2.0</version>
</dependency>
<dependency>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework-impl</artifactId>
<version>4.2.0</version>
</dependency>
<!--
With these versions is no longer raised the
"Unable to create envelope from given source"
exception explained before
-->
<dependency>
<groupId>xalan</groupId>
<artifactId>xalan</artifactId>
<version>2.7.0</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.9.1</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
</exclusions>
</dependency>
Hope it helps.

NoSuchMethodError: org.slf4j.impl.StaticLoggerBinder.getSingleton()

The issue was caused by one of the dependencies in my pom.xml [cxf-bundle-jaxrs] which internally uses lower version of slf4j. I managed to resolve this issue by upgrading this dependency to the latest release. Thanks everyone.
I'm trying to add Apache Shiro to my CXF Spring web application. When I start up my tomcat 7 I get the following error
Caused by: java.lang.NoSuchMethodError: org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder;
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
at org.apache.shiro.spring.LifecycleBeanPostProcessor.<clinit>(LifecycleBeanPostProcessor.java:51)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:61)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:877)
... 25 more
and my pom.xml for shiro and slf4j is
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-core</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-web</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-spring</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.1</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
<scope>runtime</scope>
</dependency>
I have tried every possible solution by googling, but no luck.
Caused by: java.lang.NoSuchMethodError: org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder;
This means that you have the class StaticLoggerBinder in your classpath.
But the class of your classpath does not have the method getSingleton()
This usually happens when you have dependencies that both use the same transitive dependency. This means that 2 of your dependencies (or your app, and a transitive dependency) are both using SLF4J internally with different versions. But your app can only use a single version of the class at the same time so it has to choose (don't know the rules here... random?)
To solve the problem, you usually need to do a mvn dependency:tree to see which are using different versions of SLF4J.
The solution is often to use a maven dependency exclusion on the lowest version. Libraries like SLF4J tend to be retrocompatible which means newer versions keep adding more features. Sometimes, a method is removed and then you have to keep the old library version, and pray. If this doesn't work there are still some options, like JarJar
But for logging libraries it's sometimes a bit different, so my explaination is for general purpose, but it's probable you do not use the right logging library dependencies because they have very special packagings which are not always easy to understand :)
Check what I found for you:
https://github.com/qos-ch/slf4j/blob/SLF4J_1.5.5/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
https://github.com/qos-ch/slf4j/blob/SLF4J_1.5.6/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
The getSingleton() method appeared at version 1.5.6, so it is very probable that you have a library that uses an SLF4J version older that 1.5.6 :) You just need to exclude it with a maven exclusion (and pray).
Edit: you should try:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle-jaxrs</artifactId>
<version>2.2</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Better, if you have a multimodule maven project with a parent pom you can use this with maven dependencyManagement xml node.
You need to include this dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
</dependency>
Something seems to be not compatible with those sl4j-api and log4j versions.
Try this link and find the correct and compatible dependencies and use them.
May be you should try the following combination,
SLF4J API Module 1.7.5 The slf4j API
SLF4J LOG4J-12 Binding 1.7.5 SLF4J LOG4J-12 Binding
Or, if you are planning to use version 1.6.1
<!-- slf4j-log4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.1</version>
</dependency>
Adding this dependency solved the issue for me
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
</dependency>

java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory

I am facing this error while running my GWT application.
I have these jar files in my classpath: slf4j-api & slf4j-log4j12
Any idea what could be the reason?
This problem is due to a change in slf4j-log4j12 jar. From version 1.5.6 it doesn't allow to access the field org.slf4j.impl.StaticLoggerBinder.SINGLETON.
To resolve it, use the newest jars (or at least version 1.5.6 onward) for both slf4j-api & slf4j-log4j12.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.6</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.6</version>
</dependency>
Finally resolved this problem in my SpringBoot application. If updating version is not helping this might help. Sometimes other libraries might bring different versions of this dependencies. These are the steps:
By error stack trace figure out which dependency is giving this issue
Get maven dependency plugin tree. Using this tree details find out if this library is coming as part of the some other dependency. In my case, the logback-classic and log4j-over-slf4j were giving this problem. They came together under spring-boot-starter-web
Use <exclusions><exclusion></exclusion></exclusions> in your pom.xml in that dependency for the libraries that giving this issue. In my case it looks like this:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<artifactId>logback-classic</artifactId>
<groupId>ch.qos.logback</groupId>
</exclusion>
<exclusion>
<artifactId>log4j-over-slf4j</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>
References:
http://www.slf4j.org/faq.html#IllegalAccessError
http://www.slf4j.org/codes.html#multiple_bindings

Categories