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

遇到

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

查看log是否提示：

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

如果是表明已经有多个logging实现，如logback/slf4j-log4j/slf4j-jcl...

确保在同一个classpath下只有一个logging实现。

另外，在Jar包根目录下的logback.xml文件是会加载到classpath里面。

参考：

https://groups.google.com/forum/#!topic/liftweb/QB_bMgsQBwU

以下内容摘自： http://www.slf4j.org/codes.html#multiple_bindings

Multiple bindings were found on the class path

SLF4J API is designed to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings.

When multiple bindings are available on the class path, select one and only one binding you wish to use, and remove the other bindings. For example, if you have bothslf4j-simple-1.7.6.jar andslf4j-nop-1.7.6.jar on the class path and you wish to use the nop (no-operation) binding, then removeslf4j-simple-1.7.6.jar from the class path.

The list of locations that SLF4J provides in this warning usually provides sufficient information to identify the dependency transitively pulling in an unwanted SLF4J binding into your project. In your project's pom.xml file, exclude this SLF4J binding when declaring the unscrupulous dependency. For example, cassandra-all version 0.8.1 declares bothlog4j andslf4j-log4j12 as compile-time dependencies. Thus, when you includecassandra-all as a dependency in your project, thecassandra-all declaration will cause bothslf4j-log4j12.jar and log4j.jar to be pulled in as dependencies. In case you do not wish to use log4j as the the SLF4J backend, you can instruct Maven to exclude these two artifacts as shown next:

<dependencies>
  <dependency>
    <groupId> org.apache.cassandra</groupId>
    <artifactId>cassandra-all</artifactId>
    <version>0.8.1</version>

    <exclusions>
      <exclusion> 
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
      </exclusion>
      <exclusion> 
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
      </exclusion>
    </exclusions> 

  </dependency>
</dependencies>

Note The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random. As of version 1.6.6, SLF4J will name the framework/implementation class it is actually bound to.

Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.