一，日志架构历史
1.1log4j
很多年前，一个叫 Ceki Gülcü 的大佬在一个项目中开发跟踪 API，这套跟踪 API 逐步演变成 log4j, 大概1999年，log4j 成为 Apache 的一员。
1.2JUL
JUL：java.util.logging
Apache 觉得 log4j 很有价值，就推荐给 SUN 公司（Java 语言是由 SUN 公司的 James Gosling 发明的），希望 SUN 公司在 JDK 中加入 log4j，SUN 公司也觉得加入日志 API 很有必要，但是又看不上 log4j，于是便自己搞了一套官方的，于 2002 年 JDK 1.4 中实现了 JUL。
此时，市面上就有两套日志 API：来自 Apache 的 log4j 和来自官方的 JUL。
1.3 JCL和 Simple Log
JCL：Jakarta Commons Logging
log4j 和 JUL 是两套不同的 API。一个出现较早、一个是官方的，两个用户群体都较大。如果在项目中想要切换日志框架就需要改动大量代码，同时这也不符合”面向接口编程“的设计原则。Apache 就推出了 JCL 项目，名字看着高大上，但这玩意儿就是在 SSH、SSM 时代到处都能看见，那就是搭建框架时经常会看到的 commons-logging 包，该项目是一套日志的抽象层（后来大神们针对这种日志的抽象层一个高端的名字——日志门面）。所谓”抽象层“，本质上就是一堆接口，有接口就需要有实现，没有实现那就是自娱自乐，没有鸟用。所以 Apache 针对 JCL 提供了一个默认实现，那就是 Simple Log。
JCL 基于动态绑定来实现日志的记录：开发过程中使用 JCL 定义的接口，程序运行的时候使用类路径 classpath 中的具体实现（Simple Log、log4j、JUL）。
JCL 的出现，日志体系显得比较优雅，面向 JCL 的接口编程，可以很方便的切换日志框架。在这个时候， log4j他爹Ceki Gülcü因为一些未知的原因离开了 Apache.
1.4 slf4j
slf4j：Simple Logging Facade for Java
写代码的人大多有个共性：别人写的都是垃圾、自己昨天写的代码也是垃圾，只有自己现在写的才是最好的。Ceki Gülcü 这哥们同样觉得 JCL 不是特别完美，于是自己又搞了一套新版本的日志接口（高端的名字是：日志门面）：slf4j。问题来了，slf4j 只有接口没有实现，难不成要让 log4j 和 JUL 都来实现 slf4j 吗？肯定是不可能的。
JCL 是采用动态绑定机制，而 slf4j 采用”桥接包“，也就是分别开发 log4j 和 JUL 的桥接包，通过桥接包来适配两者。大牛就是大牛，Ceki Gülcü提供了这些桥接包 slf4j-log4j、slf4j-jdk14等。由于 JCL 出现比 slf4j 早，很多项目使用了 JCL，所以这大佬也提供了 slf4j-jcl。
还有一种常见：在某个项目中使用了一个第三方框架，这个项目使用了 slf4j 和 log4j，而依赖的第三方框架使用了 JCL 和 JUL，这时候系统就会有两种日志配置文件和两种打印方式，乱七八糟的。 Ceki Gülcü 也考虑到这种场景，没有他的桥接包搞不定的场景，于是就弄了个 jcl-over-slf4j 的桥接包..
1.5 logback
Ceki Gülcü 弄了 slf4j 和一堆桥接包，2006 年为 slf4j 提供了一个很厉害的实现：logback。与此同时他还特意写了一篇文章《Reasons to prefer logback over log4j》。毕竟 log4j 也出自于他的手，里面存在什么问题他最清楚。事实上，logback 的性能和设计确实比 log4j 更厉害，与时俱进嘛。
1.6log4j2
logback 的出现让 Apache 坐不住了，2012年推出了新项目 log4j2。看名字像是 log4j的升级版，实际上是一个全新的玩意，它不兼容log4j。log4j2 几乎包括了 logback的特性。竞争是残酷的，与slf4j类似，log4j2也想统一日志的天下，也弄了一堆桥接包，通过桥接包 log4j-xxx 去兼容上面各种各样的日志框架...乱七八糟扯了一堆，核心就三个概念：
- 日志门面：JCL(Apache )、slf4j(Ceki )
- 日志产品：log4j(Ceki )、JUL(JDK)、logback(Ceki )、log4j2(Apache )
- 桥接包：slf4j-xxx、log4j-xxx