ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext

[Damian H]

Hi,

When I run up my app in a standalone Jetty installation on my development machine (Windows / Cygwin) all is OK, but when I try to run it on my test machine (Ubuntu), I get:

SLF4J: The requested version 1.5.6 by your slf4j binding is not compatible with [1.6]

SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.

2011-08-02 16:11:09.564:WARN::failed LiftFilter: java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot

be cast to ch.qos.logback.classic.LoggerContext

2011-08-02 16:11:09.564:WARN::Failed startup of context org.mortbay.jetty.webapp.WebAppContext@4bd27069{/mediahub,file:/

usr/share/jetty-6.1.26/webapps/mediahub.war}

java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext

        at net.liftweb.common.Logback$.withFile(Logging.scala:324)

As far as I can tell (so far), the two environments are identical. On both machines I'm running jetty 6.1.26, and it's the same war file copied into both environments.

Anybody got any ideas where I might start looking for the cause of this error? 

Thanks in advance for any suggestions.

Thanks

Damian.

[earthling_paul]

Hi Damian,

It looks as if you have got another slf4j in your Classpath on the
Ubuntu machine.
You might re-check your logfile for lines such as:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in...

Doing so helped us to find the culprits when we came accross this.

Regards
Paul

On Aug 2, 5:28 pm, Damian H <damianhe...@gmail.com> wrote:
> Hi,
> When I run up my app in a standalone Jetty installation on my development
> machine (Windows / Cygwin) all is OK, but when I try to run it on my test
> machine (Ubuntu), I get:
>
> SLF4J: The requested version 1.5.6 by your slf4j binding is not compatible
> with [1.6]

> SLF4J: Seehttp://www.slf4j.org/codes.html#version_mismatchfor further

[Damian H]

Hi Paul, 

Thanks for your reply.

Yes I do have the following lines in the log files:

SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/C:/cygwin/tmp/Jetty_0_0_0_0_8080_mediahub.war__mediahub__t4cmwh/webapp/WEB-INF/lib/lo

gback-classic-0.9.26.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/C:/cygwin/tmp/Jetty_0_0_0_0_8080_mediahub.war__mediahub__t4cmwh/webapp/WEB-INF/lib/sl

f4j-log4j12-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

I guessed that the warning was fairly benign, as ://www.slf4j.org/codes.html#multiple_bindings says "Note that the warning emitted by SLF4J is just that, a warning. SLF4J will still bind with the first framework it finds on the class path." 

I'm wanting it to bind to logback and all seems to be OK on my dev machine despite the warning. 

However, I've just notice that on the test machine, the message is actually different:

SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/tmp/Jetty_0_0_0_0_80_mediahub.war__mediahub__.ty2wg7/webapp/WEB-INF/lib/slf4j-log4j12

-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/tmp/Jetty_0_0_0_0_80_mediahub.war__mediahub__.ty2wg7/webapp/WEB-INF/lib/logback-class

ic-0.9.26.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

i.e. it finds slf4j-log4j12-1.5.6.jar before the logback-classic-0.9.26.jar

I'll carry on looking into why it's different and whether it's important.

Thanks

Damian

[Christopher Taylor]

in general, I try to have only one logging backend implementation
(logback/slf4j-log4j/slf4j-jcl) on the classpath and use the slf4j
bridges (*-over-slf4j) to redirect the other apis to slf4j. The
diagram at [1] explains this approach very well.

I've run into problems where various libs pull in commons-logging via
transitive dependencies. For maven, you can use exclusions[2] to get
rid of it again (not sure whether/how sbt supports this);
alternatively you can include a dependency on a "fake" c-l
implementation to override the transitive dep [3], or include a
dependency with scope "provided" [4].

Hope that helps and regards,
--Chris

[1]: http://www.slf4j.org/legacy.html
[2]: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
[3]: http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
[4]: http://www.insaneprogramming.be/?p=111 (see "update" at the end
of the article. I haven't used this approach myself but it seems to
make sense)

[Damian H]

Hi Chris,

Thanks for your suggestions. After reading through your references I
came to the conclusion (I think) that I don't need a 'bridge' - all I
need to do is get the slf4j-log4j12 jar off the classpath.

Here's how I did it:

1) in ~/.ivy2/cached there are a whole load of xml files that describe
the transitive dependencies. Browsing through there I saw that a
library I was including (eu.medsea.mimeutil.mime-util) was pulling in
slf4j-log4j12
2) To stop sbt from adding slf4j-log4j12.jar into the war file, I
added
ivyXML := <dependencies>
<dependency org="eu.medsea.mimeutil" name="mime-util"
rev="2.1.3" >
<exclude module="slf4j-log4j12" />
</dependency>
</dependencies>
into build.sbt (for sbt 0.10.1)

Bingo - all seems to work fine now!

Thanks again for the help.

Damian.

On Aug 3, 1:03 pm, Christopher Taylor <ccmtay...@gmail.com> wrote:
> in general, I try to have only one logging backend implementation
> (logback/slf4j-log4j/slf4j-jcl) on the classpath and use the slf4j
> bridges (*-over-slf4j) to redirect the other apis to slf4j. The
> diagram at [1] explains this approach very well.
>
> I've run into problems where various libs pull in commons-logging via
> transitive dependencies. For maven, you can use exclusions[2] to get
> rid of it again (not sure whether/how sbt supports this);
> alternatively you can include a dependency on a "fake" c-l
> implementation to override the transitive dep [3], or include a
> dependency with scope "provided" [4].
>
> Hope that helps and regards,
>   --Chris
>
> [1]:http://www.slf4j.org/legacy.html

> [2]:http://maven.apache.org/guides/introduction/introduction-to-optional-...
> [3]:http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-...
> [4]:http://www.insaneprogramming.be/?p=111(see "update" at the end

[Gursahib Singh Sahni]

Due to an already existing dependency of SLF4J in your project or in some other inherited project, there might be conflicts during runtime. Adding an exclusion to my POM file worked for me:

        <exclusions>

            <exclusion>

                <groupId>org.slf4j</groupId>

                <artifactId>slf4j-log4j12</artifactId>

            </exclusion>

        </exclusions>