110

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.

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
Carl Smotricz
  • 66,391
  • 18
  • 125
  • 167

3 Answers3

113

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.

Holger Hoffstätte
  • 1,918
  • 1
  • 13
  • 10
  • 2
    That worked right away, of course; thank you very much! I hadn't used 1.6.1 of those jars because they didn't appear to be available. I'm highly annoyed at m2eclipse, which purports to show me all available versions yet mysteriously drops a significant number of them. – Carl Smotricz Aug 20 '10 at 07:45
  • 1
    Just for interest of anyone else following: I ended up with a red arrow in the dependency graph because even the latest logback-core insists on slf4j-1.6.0. It took some more diddling around with versions until all the red arrows disappeared, but now it's both working and all blue arrows. – Carl Smotricz Aug 20 '10 at 08:32
  • 1
    How exactly do I do that. – user1721803 Sep 23 '14 at 23:29
41

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.

enter image description here

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
23

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 workaround is exclude the component and then manually depends 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>
djm.im
  • 3,295
  • 4
  • 30
  • 45
Peter L
  • 2,921
  • 1
  • 29
  • 31