As per discussion: - http://mail-archives.apache.org/mod_mbox/jmeter-dev/201510.mbox/%3CCAH9fUpYA0vzikYpOVb9WpG9%3DawcYdvE540o8%3DFPKqs0%2BN5pyLw%40mail.gmail.com%3E Switch from LogKit (Avalon/Excalivur) to Log4J2 + SLF4J
Hi, we at octoperf.com have dependencies on JMeter maven artifacts to support importing JMeter scripts. Due to slf4j.impl.StaticLoggerBinder being patched in ApacheJMeter_core:3.0, we cannot upgrade from version 2.13. This patched binder has hardcoded dependency on JMeter's LogkitLoggerFactory, which itself depends on Jorphan and logkit. This causes slf4j binding conflicts in our application making any JMeter 3.0 maven artifact unusable as dependency: SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/ubuntu/.m2/repository/org/apache/jmeter/ApacheJMeter_core/3.0/ApacheJMeter_core-3.0.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/ubuntu/.m2/repository/ch/qos/logback/logback-classic/1.1.7/logback-classic-1.1.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. Is it possible to address this issue in a 3.0.1 fix version? We are completely stuck upgrading jmeter for now. I would suggest to: - move the logkit StaticLoggerBinder into a separate jar, - add this separate log jar to jmeter's classpath, - remove any dependency to logkit / jorphan loggers in Apache JMeter code, and rely on SLF4J instead. This would allow to completely control which logger is used by JMeter components and safely integrate jmeter's API into any existing java application.
Thanks for report. Can you open a dedicated bug for this with your previous content. Contribution through patch is welcome. Regards
Closing this one as solved as Bug 59777 has been opened for the bug reported by Jerome Loisel
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3755