日志框架升级

日志框架升级

前言

最近团队一个应用做平台化改造，应用中存在多个日志实现框架，这些框架并非应用自己引入，而是依赖了的N多二方包存在中间依赖，被迫引入到应用当中。仔细梳理后，发现这些中间依赖存在log4j1、logback等。团队目标是升级到性能提升很大的log4j2，在这个过程遇到一些问题，通过查阅ATA等资料也有所收获。

升级过程

采坑一

刚开始第一直觉是，既然是升级Log4j2，把Log4j1和Logback的相关依赖全部排除，再引入log4j2的相关依赖就好了。按照这样的思路，禁用MavenHelper插件，我很快排除了Log4j1和Logback的相关依赖。但是发现应用无法启动了，原因是应用中引入了UIC的一个二方包，二方包存在这样的代码，如下：

由于项目中排除了Log4j1和Logback，二方包中通过反射来检测这2个日志框架有没有实现类，Log4j2又搞了个TODO，显然静态代码块会抛出异常，应用就无法启动了。

日志框架

上述遇到的问题，找到了应用负责人，期望对方升级一下jar包，兼容一下log4j2，但是感觉遥遥无期。按照作者的观点，应用代码中最好使用Slf4j里面的“门面”类，具体实现让Slf4j去找对应的实现，二方包中强依赖一个日志框架，让应用方很难处理。虽然我们一直在使用日志，但是很多人当遇到日志框架冲突时估计也一脸蒙蔽。
常见的日志实现框架大致有以下几种：

日志实现框架

Log4j

Log4j是一个广泛使用的日志框架，随着技术的迭代，逐渐被性能更好的Logback和Log4j2替代，其实现核心依赖如下：

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
</dependency>

Logback

Logback的核心依赖如下：

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
</dependency>

Log4j2

Log4j2相对Log4j提升巨大，API发生了巨大变化，为了区分Log4j2和Log4j，两者的包名也Apache也故意区分了，前者是org.apache.logging.log4j，而后者是org.apache.log4j，注意区分。Log4j的核心依赖如下：

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
</dependency>
<dependency>
    <groupId>