SLF4J Defaulting to Log4j over logback even when binding doesn't exist - java

I am trying to get SLF4J to bind to logback, but it is instead defaulting to Log4j.
I have all the default config files configured for logback, as well as the bindings.
My classpath has the following relevant jars:
logback-classic
commons-logging (99.0-does-not-exist) //empty jar to exclude commons-logging
logback-core
logback-ext-spring
Note: No log4j dependencies are present.
This is a spring mvc app.
On startup SLF4J has the following output:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/masierp/Documents/springsource/vfabric-tc-server-developer-2.8.2.RELEASE/blablahbkla/wtpwebapps/ilm-engine/WEB-INF/lib/activemq-all-5.7.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/masierp/Documents/springsource/vfabric-tc-server-developer-2.8.2.RELEASE/blablahbkla/wtpwebapps/ilm-engine/WEB-INF/lib/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Note that none of the found bindings are log4j bindings.
I have messed with spring-ext (trying to use it as the spring listener) but with or without this jar the problem persists.
Any help appreciated, thanks.

Probably one of your dependencies has a log4j dependency. You need to exclude it.
Try to look on the parent pom.

Related

How to disable slf4j in jetty

I am using a self code logger and i dont want implement to slf4j.
And Jetty will prints:
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
How to disable this stupid output?
Im not using Spring or something like that. I just import jetty library and it prints...
Use a slf4j-nop logger
Add this in dependencies block of build.gradle
kotlin DSL:
implementation("org.slf4j:slf4j-nop:2.0.0-alpha1")

SoapUI SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder”

How to resolve the problem of 'SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder”' when running SoapUI (mine is 5.2.1) command-line testrunner.bat?
NOTE: This problem had been answered in a number of places for Maven, Eclipse, etc. but not for SoapUI. E.g.:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". in a Maven Project
The problem, as explained in http://www.slf4j.org/codes.html is that one (and only one) of the following is missing in the classpath: slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar.
I found that adding, e.g. slf4j-simple.jar to [SoapUI-Base]/bin/ext did not work, even though it apparently loaded it:
13:02:26,203 INFO [SoapUI] Adding [C:\Program Files\SmartBear\SoapUI-5.2.1\bin\ext\slf4j-simple-1.6.1.jar] to extensions classpath
13:02:26,983 INFO [DefaultSoapUICore] initialized soapui-settings from [C:\Users\XXX\soapui-settings.xml]
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
What worked was to place slf4j-simple.jar, and more specifically, slf4j-simple-1.6.1.jar (to be compatible with the SLF4J version used in SoapUI 5.2.1) into [SoapUI-Base]/lib.
Hope this helps.
this is solution that help me.
I have downloaded last slf4j package from http://www.slf4j.org/download.html
Delete from SmartBear\SoapUI-5.2.1\lib file slf4j-api
Insert to the SmartBear\SoapUI-5.2.1\lib files from package slf4j-api and slf4j-nop
Now everything works fine.

Maven SLF4J: Class path contains multiple SLF4J bindings [External dependencies]

I know I can exclude one of the binding which I did in maven so my springboot.jar only contains logback and logback-slf bindings but then there is this external jar that I am referring on spring-boot class path introduces slf4j-log4j binding at runtime and gets confused.
java -Dprofile=dev -Dloader.path=springboot.jar,/usr/local/hadoop/lib,/usr/local/hbase/lib -jar springboot.jar
SLF4J: Found binding in [jar:file:/runtime/external/classpath/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/build/jar/path/springboot.jar!/lib/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
How do I resolved this when binding conflict is with external dependencies?
Thanks
You have to somehow exclude those jars from your classpath. So you shouldn't add the hbase lib dir in general, but enumerate all jarfiles.
In case you are using bash to start your application you can leverage its pattern matching: /usr/local/hbase/lib/!(slf4j-log4j12-*)
p.s. this is not a spring-boot question....

activemq dependency does not work well with logback

At the moment when I run my program , I get the following in my console:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/.m2/repository/ch/qos/logback/logback-classic/1.1.1/logback-classic-1.1.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/.m2/repository/org/apache/activemq/activemq-all/5.9.0/activemq-all-5.9.0.jar!/org/slf4j/impl/StaticLoggerBinder.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]
As stated in the issue here "there is no way for us to use maven dependency exclusions command to not take the activemq-all contributed slf4j-log4j12 artifact."
I'm not sure I follow the work around for it for now. Does it mean I have to use 5.10-SNAPSHOT? I was going to settle for activemq-core like the answer in this question, but I need stuff that are released in 5.9.0 and the core only goes up to 5.9. I hope someone can give me suggestions please. I really need help.
Typically, if activemq-all does not fit your needs, start with the activemq-client jar instead.
The old activemq-broker jar was cut into several pieces some versions back.
You might want the JMS specs included as well:
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jms_1.1_spec</artifactId>
<version>1.1.1</version>
</dependency>

Does slf4j use commons-logging implementation by default?

I have only worked with log4j in the past. Now I am scouting a new project and noticing that it uses slf4j 1.7.2. I understand it is only an API specification which provides a simplified interface (AKA facade) to various implementations that conform to it, such as java.util.logging, log4j and logback. However, I noticed that commons-logging wasn't mentioned in the list on the API web site, however, its jar was in this app's classpath. When I removed it from the classpath to check whether it was the used implemetation, I confirmed that it indeed was:
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.
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
Is commons-logging indeed the default implementation for slf4j? Because their documentation says:
If no binding is found on the class path, then SLF4J will default to a no-operation implementation.
at the above linked page. And even though I have slf4j-nop-1.7.2.jar in the classpath, which I am guessing the default implementation referred to above is, I still get the exception asking for org/apache/commons/logging/LogFactory if the commons is not in the classpath, so I am confused.
A clarification would be appreciated.
You need a combination of the binding jar AND the logging implementation (JCL in this case) on the classpath.
Binding with a logging framework at deployment time
commons-logging is not the default, but if you have slf4j-jcl-1.7.2.jar on your classpath, it will try to use that. So if you therefore remove JCL from your path, it will complain that it can't find the classes.
slf4j-nop-1.7.2.jar is the no-op "SLF4J bindings" jar, not an implementation in itself.

Categories