一、日志门面
当我们的系统变的更加复杂的时候，我们的日志就容易发生混乱。随着系统开发的进行，可能会更新不同的日志框架，造成当前系统中存在不同的日志依赖，让我们难以统一的管理和控制。就算我们强制要求所有的模块使用相同的日志框架，系统中也难以避免使用其他类似spring,mybatis等其他的第三方框架，它们依赖于我们规定不同的日志框架，而且他们自身的日志系统就有着不一致性，依然会出来日志体系的混乱。
所以我们需要借鉴JDBC的思想，为日志系统也提供一套门面，那么我们就可以面向这些接口规范来开发，避免了直接依赖具体的日志框架。这样我们的系统在日志中，就存在了日志的门面和日志的实现。
常见的日志门面 ：
JCL、slf4j
常见的日志实现：
JUL、log4j、logback、log4j2
日志框架出现的历史顺序：
log4j -->JUL-->JCL--> slf4j --> logback --> log4j2
二、JCL
全称为Jakarta Commons Logging，是Apache提供的一个通用日志API。
它是为 "所有的Java日志实现"提供一个统一的接口，它自身也提供一个日志的实现，但是功能非常常弱（SimpleLog）。所以一般不会单独使用它。他允许开发人员使用不同的具体日志实现工具: Log4j, Jdk自带的日志（JUL)
JCL 有两个基本的抽象类：Log(基本记录器)和LogFactory(负责创建Log实例)。
1. JCL入门
? 依赖
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>? 代码
@Test
public void test1(){
// 获取 log日志记录器对象
Log log = LogFactory.getLog(demo1.class);
log.fatal("fatal"); // 严重错误，一般会造成系统崩溃并终止运行
log.error("error"); // 错误信息，不会影响系统运行
log.warn("warn"); // 警告信息，可能会发生问题
log.info("info"); // 运行信息，数据连接、网络连接、IO 操作等等
log.debug("debug"); // 调试信息，一般在开发中使用，记录程序变量参数传递信息等等
log.trace("trace"); // 追踪信息，记录程序所有的流程信息
}输出 默认info级别 默认使用java自带的jul日志框架 |
2. 加入log4j依赖
依赖 配置文件 输出结果 |
总结：我们无需修改代码，只需要修改日志门面的实现即可切换日志框架
三、SLF4J的使用
简单日志门面(Simple Logging Facade For Java) SLF4J主要是为了给Java日志访问提供一套标准、规范的API框架，其主要意义在于提供接口，具体的实现可以交由其他日志框架，例如log4j和logback等。
当然slf4j自己也提供了功能较为简单的实现，但是一般很少用到。对于一般的Java项目而言，日志框架会选择slf4j-api作为门面，配上具体的实现框架（log4j、logback等），中间使用桥接器完成桥接。
SLF4J是目前市面上最流行的日志门面。现在的项目中，基本上都是使用SLF4J作为我们的日志系统。
1. 入门
? 依赖
<!--slf4j core 使用slf4j必須添加-->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.27</version>
</dependency>
<!--slf4j 自带的简单日志实现 -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.27</version>
</dependency>? 自带日志实现
代码 输出 |
2. 绑定日志的实现（Binding）
SLF4J支持各种日志框架。SLF4J发行版附带了几个称为“SLF4J绑定”的jar文件，每个绑定对应一个受支持的框架。
使用slf4j的日志绑定流程:
1. 添加slf4j-api的依赖
2. 使用slf4j的API在项目中进行统一的日志记录
3. 绑定具体的日志实现框架
绑定已经实现了slf4j的日志框架,直接添加对应依赖
绑定没有实现slf4j的日志框架,先添加日志的适配器,再添加实现类的依赖
3. slf4j有且仅有一个日志实现框架的绑定（如果出现多个默认使用第一个依赖日志实现）
? 与log4j整合
依赖 代码 输出 结合log4j 就需要配置log4j的配置文件 |
? 与jul整合
依赖 代码 输出 |
? 与jcl整合
依赖 输出 |
? 与nop整合
依赖 输出 |
4. 桥接旧的日志框架（Bridging）
我们依赖的某些组件依赖于SLF4J以外的日志记录API。可以假设这些组件在不久的将来不会切换到SLF4J。为了解决这种情况，SLF4J附带了几个桥接模块，这些模块将对log4j，JCL和java.util.logging API的调用重定向，就好像它们是对SLF4J API一样。
桥接解决的是项目中日志的遗留问题，当系统中存在之前的日志API，可以通过桥接转换到slf4j的实现
1. 先去除之前老的日志框架的依赖
2. 添加SLF4J提供的桥接组件
3. 为项目添加SLF4J的具体实现
? 案例
例如我们之前所用的框架为jcl，由于项目变更需要将日志换成slf4j加log4j，此时代码将会报错，所以需要使用slf4j的桥接器
原始代码： 依赖： 代码 输出 由于业务需求需要改为slf4j加log4j 此时注释掉jcl依赖 代码报错 使用桥接器 依赖 发现此时代码不在报错 输出：发现此时输出的已经是log4j的日志 |
? 迁移的方式：
如果我们要使用SLF4J的桥接器，替换原有的日志框架，那么我们需要做的第一件事情，就是删除掉原有项目中的日志框架的依赖。然后替换成SLF4J提供的桥接器。
<!-- log4j-->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.27</version>
</dependency>
<!-- jul -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.27</version>
</dependency>
<!--jcl -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.27</version>
</dependency>注意问题：
1. jcl-over-slf4j.jar和 slf4j-jcl.jar不能同时部署。前一个jar文件将导致JCL将日志系统的选择委托给SLF4J，后一个jar文件将导致SLF4J将日志系统的选择委托给JCL，从而导致无限循环。
2. log4j-over-slf4j.jar和slf4j-log4j12.jar不能同时出现
3. jul-to-slf4j.jar和slf4j-jdk14.jar不能同时出现
4. 所有的桥接都只对Logger日志记录器对象有效，如果程序中调用了内部的配置类或者是Appender,Filter等对象，将无法产生效果。
