前言
本文介绍个人对 logging 包下源码的理解。分享出来供大家参考学习，下面话不多说了，来一起看看详细的介绍吧
logging 配置加载
我们先从日志的配置加载开始阅读， mybatis 的各项配置的加载过程都可以从 xmlconfigbuilder 类中找到，我们定位到该类下的日志加载方法 loadcustomlogimpl：
|
1
2
3
4
5
6
7
8
|
private void loadcustomlogimpl(properties props) { // 从 mybatis 的 typealiasregistry 中查找 logimpl 键所对应值的类对象 // 这里 logimpl 对应的 value 值可以从 org.apache.ibatis.session.configuration 的构造方法中找到 // 注意 log 类，这是 mybatis 内部对日志对象的抽象 class<? extends log> logimpl = resolveclass(props.getproperty("logimpl")); // 将查找到的 class 对象设置到 configuration 对象中 configuration.setlogimpl(logimpl);} |
很简单的一个方法，每行都有注释，其中 configuration.setlogimpl() 里面调用了 logfactory.usecustomlogging() ，这出现了新类 logfactory 类，接下来我们就来聊聊这个类。
logfactory
usecustomlogging()方法
logfactory 是框架内部获取 log 对象的手段，通过它的名字也能看出来。它有如下几类方法：
|
1
2
3
4
5
6
7
8
|
// 注意这个类型的方法都是同步方法public synchronized static usexxxlogging(...);public static log getlog(...);private static tryimplementation(runnable);private static setimplementation(class); |
刚刚我们看到被调用的方法 usecustomlogging() 方法，是用来设置内部使用的日志框架， mybatis 自身已经适配了一些常见的日志框架，如 slf4j 、 commons log 、 log4j 等等。
usecustomlogging() 方法内部调用 setimplementation(class) 方法，此方法代码如下，功能简单：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
private static void setimplementation(class<? extends log> implclass) { try { // 获取 log实现类的构造方法，它只有一个字符串作为参数 constructor<? extends log> candidate = implclass.getconstructor(string.class); // 创建一个 log 对象，打印 debug 日志 log log = candidate.newinstance(logfactory.class.getname()); if (log.isdebugenabled()) { log.debug("logging initialized using '" + implclass + "' adapter."); } // ... // 把 candidate 对象设置到 logfactory 的静态变量 logconstructor，这个静态变量在 getlog() 方法 // 中被用到 logconstructor = candidate; } catch (throwable t) { throw new logexception("error setting log implementation. cause: " + t, t); }} |
log 接口
刚刚我们接触到了 log 这个类，它是一个接口，是 mybatis 内部使用的日志对象的抽象，它是为了兼容市面上各种各样的日志框架，使用了适配器模式，通过 log 接口来连接 mybatis 和其他日志框架，通过实现 log 接口连着 mybatis 和需要适配的日志框架。
log 接口代码如下，先试着发现该接口与其他常见的日志接口的区别：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
public interface log { boolean isdebugenabled(); boolean istraceenabled(); void error(string s, throwable e); void error(string s); void debug(string s); void trace(string s); void warn(string s);} |
可有发现？log 接口缺少了 info 级别的日志输出方法，个人猜测应该是 mybatis 内部不需要 info 级别的日志输出，毕竟 log 接口设计之初就是为了内部使用，而框架使用者是不会采用 mybatis 的日志作为系统的日志。注意一点： 实现了 log 接口的类必须拥有一个参数只有一个字符串的构造方法 ，mybatis 就是通过这个构造方法创建日志对象的。
mybatis 适配了许多常见的日志框架，这里就单单介绍 log4jimpl 类，它代码非常简单：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
public class log4jimpl implements log { private static final string fqcn = log4jimpl.class.getname(); // 这里包装了 log4j 框架的日志对象，从而实现适配 private final logger log; public log4jimpl(string clazz) { log = logger.getlogger(clazz); } @override public boolean isdebugenabled() { return log.isdebugenabled(); } @override public boolean istraceenabled() { return log.istraceenabled(); } @override public void error(string s, throwable e) { log.log(fqcn, level.error, s, e); } @override public void error(string s) { log.log(fqcn, level.error, s, null); } @override public void debug(string s) { log.log(fqcn, level.debug, s, null); } @override public void trace(string s) { log.log(fqcn, level.trace, s, null); } @override public void warn(string s) { log.log(fqcn, level.warn, s, null); }} |
tryimplementation() 方法
logfactory 类再介绍一下被静态代码块使用的方法 tryimplementation(runnable) 。静态代码块代码如下：
|
1
2
3
4
5
6
7
8
9
|
static { // 依次执行如下代码，当没有该类会抛 classnotfoundexception ，然后继续执行 tryimplementation(logfactory::useslf4jlogging); tryimplementation(logfactory::usecommonslogging); tryimplementation(logfactory::uselog4j2logging); tryimplementation(logfactory::uselog4jlogging); tryimplementation(logfactory::usejdklogging); tryimplementation(logfactory::usenologging);} |
这个方法有点迷惑性，因为它使用 runnable 接口作为参数，而 usexxxlogging() 方法又是同步方法，很容易联想到多线程，实际上这里并没有， runnable 接口不结合 thread 类使用它就是一个普通的函数接口。除去这些就没什么了，不过是调用了 runnable 的 run() 方法而已。
getlog() 方法
getlog() 没什么多说的，就是通过反射创建 log 接口实现类，这里没有使用到缓存，每次调用都是创建一个新的对象。
jdbc 包
这个包与其他包有些不同，它的职能是为各个阶段的流程提供日志打印，该包一共就五个类，它们的关系如下：
除了 basejdbclogger 类其他类都实现了 invocationhandler 接口，这个接口是 jdk 提供的动态代理接口，所以显而易见可以知道它们就是通过代理在各个阶段打印相应的日志。
以下为 basejdbclogger 类的部分说明：
- set_methods：静态字段，记录 preparedstatement 中 set 开头的的方法名
- execute_methods：静态字段，记录 sql 执行的方法名
- columnxxx：实例字段，记录 sql 参数信息
- statementlog：日志对象
- querystack：查询栈数
- getparametervaluestring()：将 sql 参数转为一个字符串
- removebreakingwhitespace()：移除 sql 中多余的空白字符
- prefix()：获取前缀 ==>/<==
而其余四个类都是简单的逻辑：判断执行的方法是否为指定方法，然后打印相应的日志。
总结
以上便是个人研究 logging 包的内容，本包使用了以下设计模式（包含不限于）：
- 适配器模式
- 代理模式
其中适配器模式应该是一个比较不错的示例，可做参考。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对服务器之家的支持。
原文链接：https://segmentfault.com/a/1190000018365826
