slf4j-api 1.6.x (or later) is incompatible with this binding.解决方案及原理

最新推荐文章于 2023-01-15 15:27:25 发布

keke_Xin

最新推荐文章于 2023-01-15 15:27:25 发布

阅读量698

点赞数

分类专栏： Maven 文章标签：开发工具 java

本文链接：https://blog.csdn.net/keke_Xin/article/details/84816462

版权

Maven 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

前几天搭建工程的时候，每次启动总会报这个异常：

[java]view plaincopy
         
     
SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding.  
SLF4J: Your binding is version 1.5.5 or earlier.  
SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x  

然后紧跟着：

[java]view plaincopy
         
     
10:02:47.127:WARN::Nested in java.lang.ExceptionInInitializerError:  
java.lang.IllegalStateException: org.slf4j.LoggerFactory could not be successfully initialized. See also http://www.slf4j.org/codes.html#unsuccessfulInit  
    at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:277)  
    at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)  
    at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:156)  
    at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)  
    at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272)  
    at org.springframework.web.context.ContextLoader.<clinit>(ContextLoader.java:149)  
    at com.alibaba.citrus.webx.context.WebxContextLoaderListener.createContextLoader(WebxContextLoaderListener.java:40)  
    at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:44)  
    at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)  
    at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)  
    at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)  
    at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)  
    at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)  
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)  
    at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)  
    at org.mortbay.jetty.Server.doStart(Server.java:224)  
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)  
    at runjettyrun.Bootstrap.main(Bootstrap.java:259)  

从错误提示来看，是版本不兼容的问题(废话)。

首先估计是slf4j-api的版本，在每个子工程下面不一样，也许在子工程1里面是1.6.1，在子工程2里面是1.5.6，打包运行时候，出现了版本冲突导致的。

eclipse工程下——打开pom文件——选择dependecy Hierarchy ，就可以查看每个jar包以及他们之间的依赖关系。（本质上执行mvn dependency:tree命令是一样的）

查看某个工程的Pom文件，发现其中一个的Pom文件依赖关系是这样的：

其中，当我们在右上角搜索slf的时候，右边显示的是所有的jar包，橙色被选中的是匹配的同名Jar包，我们可以看到有slf4j-api：1.5.6，slf4j-log4j12：1.4.3以及jcl-over-slf4j:1.5.6；左边是工程中哪些其他Jar包间接依赖了slf4j-*，其中compile表示该版本为选中的编译版本，omitted for confict with ××× 表示因为存在×××版本，当前版本被忽略。

因此我们可以看到，slf4j-api编译版本为1.5.6，slf4j-log12编译版本为1.4.3，jcl-over-slf4j编译版本为1.5.6。如果工程中所有依赖的slf4j-api版本都是1.5.6也是允许的，但是考虑到工程整体结构，以及高版本通常兼容低版本，最重要的是只有这个一个子工程用了低版本，当然要升级到1.6.1了！

在此再罗嗦一下，简单说一下Mvn工程Pom文件中dependency之间各jar包版本的依赖关系：

A. pom文件的依赖按声明顺序上到下读取，即先声明的优先

例如：pom文件中依赖的声明顺序由上向下为：

dependency:A(1.0.1)

dependency:A(1.0.2)

那么系统依赖肯定是依赖A1.0.1，因为该依赖最先被声明，后面的被Omitted(忽略)

B. 对于间接依赖，采用最短路径优先算法，距离短的被采用，其中“—”表示间接依赖

A—B—C—D(1.0.0)

F—E—D(1.0.1)

其中A间接依赖B，B又间接依赖C，C又间接依赖D，此时路径距离为3；另一个依赖：F间接依赖E，E间接依赖D，此时路径为2；

根据最短路径优先原则，会依赖F-E-D(1.0.1)中的D(1.0.1)版本。

C. 对于间接依赖路径长度相同的，谁先声明选谁，和A的规则是一样的

A—B—C—D(1.0.0)

F—E—K—D(1.0.1)

路径长度相同，先声明者优先选取，肯定选取D(1.0.0)

综上：

如果我们想要将slf4j-api升级到1.6.1，最直接的办法就是在tair-mc-client声明之前直接声明一个slf4j-api:1.6.1的版本，或者排除tair-mc-client——tair-cient——slf4j-api:1.5.6的依赖，从而间接依赖tair-mc-client——tair-client——echache——slf4j-api:1.6.1。为了直观一点，我们选取直接声明一个slf4j-api:1.6.1版本的依赖。同时为了保证slf4j-api,slf4j-log4j12版本一致性，直接引入slf4j-log4j12:1.6.1版本，因为slf4j-log4j12:1.6.1间接依赖slf4j:1.6.1，并将其声明在文件最顶端，问题解决。

对于排除同个jar包多个版本的冲突问题：

首先是搞清楚各个Jar包之间的依赖关系：对于用eclipse工具的mvn工程，可以直接查看pom文件中的dependency Hierarchy 或者用命令 mvn dependency:tree 将依赖关系展现出来，这样就知道哪个间接的版本有问题；

然后选择合适的版本，剔除不想要的版本：通常是高版本优先，可以在Pom文件中比较靠前的位置显示声明一个高版本，或者排除某个低版本依赖；