WMS解决依赖冲突的实践-京东云开发者社区

### 1 前言
随着应用系统功能的增多，各种中间件的引入以及应用引入的各种jar的规模极具膨胀，出现jar冲突和Class冲突的问题层出不穷，让人不胜其扰。本文结合WMS系统为例，针对解决Maven依赖冲突，提供一个排查和定位问题的最佳实践。
### 2 实践
#### 2.1 问题描述
1. 所属wms5.0系统出库模块productionscheduling仓库调度系统，北斗京滨仓三个分组五台机器（10.45.1.47、10.45.1.69、10.45.1.73，10.45.1.46，10.45.1.68），其中前三台实例日志sp模块日志不切割，后两台实例业务日志切割正常，业务日志sp模块全部打印到catalina.out，其他模块日志如cxf,ta模块等打印正常。检查log4j2的配置文件配置没有问题。
![](//img1.jcloudcs.com/developer.jdcloud.com/0f90fd32-ea3e-4180-83e7-80b32651dc4120210909134428.png)
上图检查log4j2的相关配置并没有发现什么问题，如下图所示业务日志sp模块全部打印到catalina.out中导致文件高达1G。 ![](//img1.jcloudcs.com/developer.jdcloud.com/399a9842-a09f-4bcf-a6ca-1703875111ac20210909134448.png)
1. 检查productionscheduling项目以及依赖的模块使用日志依赖jar包比较混乱，如：log4j原生类、log4j2原生类、sl4j、common-log等
![](//img1.jcloudcs.com/developer.jdcloud.com/b66881ed-fbc4-42c2-9964-f3eafdbcaa4220210909134517.png)

#### 2.2 实践过程
首先回顾一下java log的日志体系如下图所示![](//img1.jcloudcs.com/developer.jdcloud.com/075e7157-f351-4338-8ed9-20edd256cc0d20210909134535.png)

如上图所示我们可以对众多的日志相关Jar包进行分类，主要分为三类：

**接口类：**只提供API定义，没有提供具体实现。目的是为应用层提供标准化的使用方式。既所谓的面向接口编程。
```
SLF4J
J.C.L(commons-logging)
```

**实现类：**具体的日志实现类，提供对日志的收集/管理功能。受不同需求/不同历史环境影响，各框架功能上有许多不同。但遵循进化论规律。
```
Log4j
J.U.L(jdk-logging)
Log4j2
Logback
```

**桥接类：**多种日志实现框架混用情况下，需要借助桥接类进行日志的转换，最后统一成一种进行输出。
```
slf4j-jdk14
slf4j-log4j12
log4j-slf4j-impl
logback-classic
slf4j-jcl
jul-to-slf4j
log4j-over-slf4j
icl-over-slf4j
log4j-to-slf4j
```

回顾完log的知识体系以后得出一个结论
接口类SLF4J需要借助桥接类slf4j-log4j12，log4j-slf4j-impl等进行转换，并且由log体系图可以得知
- **slf4j-api转换到log4j2需要借助log4j-slf4j-impl**
- **slf4j-api转换到log4j1需要借助slf4j-log4j12**

带着上面的结论，首先分析日志被切割成多个文件对应项目module,现在只有sp对应的模块不切割日志，那么说明可能对应切割日志对应模块或者父模块的依赖存在log4j相关jar的冲突或者重复，查看对应日志模块对应的项目包路径

![](//img1.jcloudcs.com/developer.jdcloud.com/a4f82d86-1862-4a0c-a26d-b61e28876e3d20210909134714.png)

由包路径定位到所属项目对应的module
![](//img1.jcloudcs.com/developer.jdcloud.com/7d02f6ae-61fb-4d28-9e2a-f508cf638e8c20210909134726.png)

定位到模块以后分析该模块的pom以及父pom，使用如下命令分析
```
  mvn dependency:tree -Dverbose
```

![](//img1.jcloudcs.com/developer.jdcloud.com/38ec3df3-a558-4bfa-817c-4da23321a21320210909134758.png)

分析依赖树冲突，发现项目中依赖log相关包重复比较多为了更直观的更方便的分析依赖使用IDEA插件
maven helper

![](//img1.jcloudcs.com/developer.jdcloud.com/fbb9f2cf-e25a-47eb-847b-9c195d8ee6f120210909134811.png)

安装好插件以后点击依赖分析

![](//img1.jcloudcs.com/developer.jdcloud.com/e2ed1c3f-d9c9-4788-838a-d7696867628920210909134844.png)

对冲突的log依赖进行排除后验证发现日志打印还是没有恢复，另外显示在父pom的依赖冲突无法在当前pom使用插件排除只能手动排除显示如下图所示：

![](//img1.jcloudcs.com/developer.jdcloud.com/399334e2-a290-4bfc-bcf7-1447e8b6de0820210909134904.png)

继续分析

![](//img1.jcloudcs.com/developer.jdcloud.com/ccabd691-553c-447a-8a0d-b0ca0c34c51820210909134917.png)

发现上图jim-cli-api中有引用slf4j包的冲突项，

![](//img1.jcloudcs.com/developer.jdcloud.com/d45d041e-0c40-4546-af12-5889687559a520210909134931.png)

进入到该依赖父pom，发现jim-cli-api父依赖如下图所示

![](//img1.jcloudcs.com/developer.jdcloud.com/cb4cb230-3196-4f99-b296-07c9cfdc1c6f20210909134952.png)

如图所示该依赖中含有slf4j的引用，版本为1.7.13，回顾项目自身引用的依赖

![](//img1.jcloudcs.com/developer.jdcloud.com/1fb6a939-c7c8-4443-bee4-2e0635d556e820210909135010.png)

如图所示桥接包使用log4j-slf4j-impl-2.3包，而jim-cli-api父依赖引入了slf4j-log4j12-1.7.13

![](//img1.jcloudcs.com/developer.jdcloud.com/5f29a4e3-f93d-4c44-95e3-8d401ace513f20210909135023.png)

说明此时项目中含有两个版本的桥接包，按照本项目日志实现类为log4j2，按照开始的结论
**slf4j-api转换到log4j2需要借助log4j-slf4j-impl。**说明slf4j-log4j12-1.7.13包是多余的会干扰日志实现类的选择。
引入思考，为什么同一服务不同实例结果不一样？
- 通过查阅官方资料发现slf4j在绑定时，如果有多个可以绑定的包，**SLF4J选择绑定的方式由JVM确定，并且出于所有实际目的应该被认为是随机的。**
- 在10.45.1.47，先加载的是log4j-slf4j-impl，后加载的是slf4j-log4j12。而10.45.1.46先加载的是slf4j-log4j12，后加载的是log4j-slf4j-impl。

**10.45..47机器：**
具体信息：
```
SLF4J:Class path contains mutiple SLF4J bindings
SLF4J:Found binding in[jar:file:/WEB-INF/lib/log4j-slf4j-impl-2.3.jar!/org/slf4j/impl/StaticLoggerBider.class]
SLF4J:Found binding in[jar:file:/WEB-INF/lib/slf4j-log4j12-1.7.13.jar!/org/slf4j/impl/StaticLoggerBider.class]
```

**10.45.1.46机器：**
具体信息：
```
SLF4J:Class path contains mutiple SLF4J bindings
SLF4J:Found binding in[jar:file:/WEB-INF/lib/slf4j-log4j12-1.7.13.jar!/org/slf4j/impl/StaticLoggerBider.class]
SLF4J:Found binding in[jar:file:/WEB-INF/lib/log4j-slf4j-impl-2.3.jar!/org/slf4j/impl/StaticLoggerBider.class]
```

经过分析，日志不分割的问题就找到了-根本原因就是lib里面有多个了slf4j可绑定的jar包slf4j-log4j12-1.7.13.jar。
#### 2.3 解决方案
经过以上分析根本原因在于jim-cli-api依赖的父pom重复引入了不同版本的slf4j-log4j12桥接包

![](//img1.jcloudcs.com/developer.jdcloud.com/d0cdad97-29bd-4e46-a49f-79672c83a43d20210909135150.png)

将其排除即可

![](//img1.jcloudcs.com/developer.jdcloud.com/408a4283-75c0-47f7-86ea-9e41a1693b9120210909135205.png)

重新编译上线之后日志正常打印

![](//img1.jcloudcs.com/developer.jdcloud.com/05213a97-e6ff-4697-919f-944d9574ca2e20210909135218.png)

### 3.总结
（1）使用SLF4j+Log4j2时使用的桥接包是log4j-slf4j-impl
（2）当有多个SLF4j的桥接包时，一定要排除不需要的包
（3) SLF4J选择绑定的方式由JVM确定，并且出于所有实际目的应该被认为是随机的
（4）引入依赖一定要慎重选择，尽量利用插件命令等分析是否有依赖冲突项。
##### 参考
https://www.cnblogs.com/zeng1994/p/df2559e6dc66c99065676e0ee70545eb.html

------------
###### 自猿其说Tech-JDL京东物流技术发展部
###### 作者：北斗星团队（网规技术部 王武杰）