SLF4J: The class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/apache-jmeter-5.4.1/apache-jmeter-5.4.1/lib/log4j-slf4j-impl-2.13.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/apache-jmeter-5.4.1/apache-jmeter-5.4.1/lib/tika-app-2.1.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 [org.apache.logging.slf4j.Log4jLoggerFactory]
How to resolve it,
and does it impact anything?
This warning can be safely ignored.
If you're interested in the reason: this guy: tika-app-2.1.0.jar is not a part of JMeter 5.4.1 and both JMeter and Tika are using SLF4J framework with their own configurations. The framework detects both bindings and warns you about their presence in the classpath
If you don't use tika-app-2.1.0.jar anywhere in your Test Plans - remove the .jar from JMeter's "lib" folder and the warning will go away, moreover this .jar is kind of big and removing it will make JMeter to start faster.
Also according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article you should always be using the latest version of JMeter so consider downloading JMeter 5.4.3 (or whatever is the latest stable version which is available at JMeter Downloads page) on next available opportunity.
Related
We are using Alluxio(alluxio-2.8.1), and very curious to see and understand what version of log4j used in it. Please suggest where we can get that information.
According to this url https://github.com/Alluxio/alluxio/blob/master/pom.xml, log4j version may be 2.17.1.
Secondly, in the archive, you can found assembly director, extract some-thing-server.jar and find log4j class.
Thirdly, may be you can extract from running log, or set log to DEBUG
We need to migrate to log4j 2.17 if we are using log4j jar, mvn dependency: tree showing only log4j-over-slf4j:jar. so I assume app is safe as it will redirect call to sl4j not to log4j.
Please confirm my app is safe with this jar without any remediation.?
In the SLF4J website, in the Comments on the log4shell(CVE-2021-44228) vulnerability they state that:
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
So it basically depends on how you're implementing the logs' generation. Slf4j natively uses logback. But to be sure, you can check your pom.xml and see if log4j is mentioned there.
I have an internal library that was upgrade to use logstash which has a mandatory dependency to logback, hence logback-classic (which has its own slf4j appender internally of its packages, which means I can't exclude any library here).
When I try to use this dependency as a jar over any other legacy module (all of them are using slf4j-log4j12) I do get the log dependency hell message:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/asdf/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/asdf/.m2/repository/org/slf4j/slf4j-log4j12/1.7.26/slf4j-log4j12-1.7.26.jar!/org/slf4j/impl/StaticLoggerBinder.class]
but the problem itself is that I can't just exclude logback-classic, since it is mandatory for logstash, and I can't migrate my applications to use logback, since they are configured with the log4j.xml
Is there a way to force slf4j to use the application appender instead of the one that comes from the logback library, OR, any other idea to make just a given package to use an appender, and the rest, use other?
When I add org.jxls dependency to pom,it seems to affect log4j outputs.I set log4j log level "ERROR",but it outputs DEBUG infomation to console.But when I remove org.jxls,log4j works right.
Although Jxls-2 uses SLF4J as a logging facade it has a dependency to Logback because it uses some if its XML processing utilities.
If you do not use Logback but another logging framework (e.g. log4j) and configured SLF4J binding you can still end up with "Class path contains multiple SLF4J bindings" warning.
Currently there is a bug in Jxls-2 to remove the Logback dependency.
Until it is fixed you may need to have a logback.xml in your classpath.
Update
The issue is now resolved in JXLS v2.2.9 .
So now it should be possible to plugin any logging framework following the instructions in SLF4J manual
I get below error and the log files is not created. I know log4j.properties is not being picked correctly
log4j:WARN No appenders could be found for logger
log4j jar is in lib and classpath
log4j.properties is in src folder and gets loaded to classes folder on build
I tried many ways to fix this error like adding services folder with log4j implementation class to fix WAS logging conflict also tried sfl4j
Has anyone found a way to fix log4j issue with WAS7 or later ?
You can troubleshoot Log4J itself by specifying the log4j.debug=true system variable. Then you'll know exactly what's going on with Log4J, internally.
Does your log4j.properties file contain any logger definitions? perhaps you can paste the file here?
I had this same problem (WAS ignoring my META-INF/services/org.apache.commons.logging.LogFactory file).
The problem was solved when I downgraded commons-logging to 1.0.3, to match WAS version. Check this article for more info.
Consider using the Java Logging framework instead, which is built into the standard Java Runtime Environment and requires no additional installations or configuration. The relevant classes are in the java.util.logging package and there is an overview of the process for using them here (it works in a very similar way to log4j).