Logging framework incompatibility

Question

I'm building a small Java app and hoping to use logback for logging.

My app has a dependency on an older project that does its logging via

org.apache.commons | com.springsource.org.apache.commons.logging | 1.1.1

...so my plan was to use

org.slf4j | jcl-over-slf4j | 1.5.6

...to redirect the JCL logging to

org.slf4j | slf4j-api | 1.6.0

...and ultimately to

ch.qos.logback | logback-classic | 0.9.22
ch.qos.logback | logback-core | 0.9.22

so my app can log through logback via its slf4j API while the old library code can log into the same location via the redirection.

Alas, this results in

java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at   org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:141)

I've tried higher and lower verision numbers on some of these jars and also digging through API documentation and such... but I'm unable to find and solve the problem.

Help, please?

Although logback is considered the "strategic" logging framework, I have some leeway in which logging mechanism I ultimately use. I'd hope to use either logback or log4j, though, and I definitely want to merge the old project's logging into whatever the "new" logging framework ends up being, via a common configuration.

Answer 1

You are mixing the 1.5.6 version of the jcl bridge with the 1.6.0 version of the slf4j-api; this won't work because of a few changes in 1.6.0. Use the same versions for both, i.e. 1.6.1 (the latest). I use the jcl-over-slf4j bridge all the time and it works fine.

Answer 2

SLF4J 1.5.11 and 1.6.0 versions are not compatible (see compatibility report) because the argument list of org.slf4j.spi.LocationAwareLogger.log method has been changed (added Object[] p5):

SLF4J 1.5.11:

LocationAwareLogger.log ( org.slf4j.Marker p1, String p2, int p3,
                          String p4, Throwable p5 )

SLF4J 1.6.0:

LocationAwareLogger.log ( org.slf4j.Marker p1, String p2, int p3,
                          String p4, Object[] p5, Throwable p6 )

See compatibility reports for other SLF4J versions on this page.

You can generate such reports by the japi-compliance-checker tool.

Answer 3

Just to help those in a similar situation to myself...

This can be caused when a dependent library has accidentally bundled an old version of slf4j. In my case, it was tika-0.8. See https://issues.apache.org/jira/browse/TIKA-556

The work around is exclude the component and then manually depend on the correct or patched version.

EG.

    <dependency>
        <groupId>org.apache.tika</groupId>
        <artifactId>tika-parsers</artifactId>
        <version>0.8</version>
        <exclusions>
            <exclusion>
                <!-- NOTE: Version 4.2 has bundled slf4j -->
                <groupId>edu.ucar</groupId>
                <artifactId>netcdf</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <!-- Patched version 4.2-min does not bundle slf4j -->
        <groupId>edu.ucar</groupId>
        <artifactId>netcdf</artifactId>
        <version>4.2-min</version>
    </dependency>