在《MyBatis是纸老虎吗？（三）》这篇文章中我们一起梳理了MyBatis配置文件的解析流程，并详细介绍了其中的一些常见节点的解析步骤。通过梳理，我们弄清楚了MyBatis配置文件中的一些常用配置项与Java Bean之间的对应关系，这进一步加深了我们对MyBatis配置文件认识；通过梳理，我们对MyBatis的使用步骤有了更全面的了解，这进一步提高了我们使用MyBatis的能力。今天我想继续梳理MyBatis这个框架，因为我们了解的，仅仅是冰山的一角。MyBatis中还有很多其他实用的知识点和好的设计思想值得我们深究。那今天就一起研究一下MyBatis配置文件中的plugins元素吧。
1 plugins元素的定义及解析
上篇文章——《MyBatis是纸老虎吗？（三）》——有提到过这个元素。这个元素的作用就是允许开发者指定一个插件，这个插件可以在映射语句执行过程中的某一点进行拦截，然后做一些特殊的处理，比如数据分页、操作日志增强、sql性能监控等。那如何定义一个插件呢？很简单，只需实现org.apache.ibatis.plugin.Interceptor接口即可。下面是一个自定义插件的示例：
@Intercepts({
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})
})
public class ExamplePlugin implements Interceptor {
private Properties properties = new Properties();
public Object intercept(Invocation invocation) throws Throwable {
// implement pre processing if need
Object returnObject = invocation.proceed();
// implement post processing if need
return returnObject;
}
public void setProperties(Properties properties) {
this.properties = properties;
}
}
这个拦截器中的intercept()方法并未做任何处理，只是调用了Invocation对象上的proceed()方法，并将该方法的执行结果返回给上级调用者。梳理到这里，我想看一下Interceptor接口的源码，如下所示：
public interface Interceptor {
Object intercept(Invocation invocation) throws Throwable;
// default xxxx，如果没有没记错的话，这是 jdk1.8的新特性
default Object plugin(Object target) {
return Plugin.wrap(target, this);
}
default void setProperties(Properties properties) {
// NOP
}
}
由此源码，我们可以知道Interceptor，拦截器，是一个接口，其中仅有一个名为intercept的方法，因此实现该接口的类一般都要对这个方法进行实现。上面展示的自定义拦截器就对这个方法进行了实现。注意：这个方法会接收一个Invocation类型的参数，该类的源码如下所示：
public class Invocation {
private final Object target;
private final Method method;
private final Object[] args;
public Invocation(Object target, Method method, Object[] args) {
this.target = target;
this.method = method;
this.args = args;
}
public Object getTarget() {
return target;
}
public Method getMethod() {
return method;
}
public Object[] getArgs() {
return args;
}
public Object proceed() throws InvocationTargetException, IllegalAccessException {
return method.invoke(target, args);
}
}
梳理到这里，我非常想知道是这个自定义拦截器要怎样用。想必诸位都已先我一步知道了这个问题的答案：直接在MyBatis的配置文件config.xml中新增plugins配置项。具体代码如下所示：
<plugins>
<plugin interceptor="包名.插件类名"></plugin>
</plugins>
进行到这里，所有的前期准备工作就完成了。下面就一起看一下这个元素的解析过程吧！通过上篇文章我们知道XMLConfigBuilder类的parse()方法开启了执行流程，其中执行解析工作的核心是与其同属一类的parseConfiguration()方法。该方法会对MyBatis配置文件中的元素按照既定顺序逐个解析。这些元素的解析顺序为：properties、settings、typeAliases、plugins、objectFactory、objectWrapperFactory、reflectorFactory、environments、databaseIdProvider、typeHandlers、mappers。上节我们一起梳理了properties、settings、typeAliases、environments四个元素的解析过程，这节就详细梳理一下plugins元素的解析过程。解析plugins元素的方法的名为pluginsElement()，其源码如下所示：
private void pluginsElement(XNode context) throws Exception {
if (context != null) {
for (XNode child : context.getChildren()) {
String interceptor = child.getStringAttribute("interceptor");
Properties properties = child.getChildrenAsProperties();
Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).getDeclaredConstructor()
.newInstance();
interceptorInstance.setProperties(properties);
configuration.addInterceptor(interceptorInstance);
}
}
}
该方法被调用时的状态如下图所示（注意截图中context参数的内容，就是MyBatis配置文件中的plugins标签下的内容）：
借助这段运行时状态图，让我们一起分析一下这段代码的执行逻辑：1.拿到context参数所代表的plugins元素下的所有plugin节点，并遍历这些节点，然后执行下述步骤；2.拿到plugin节点上interceptor属性的值，这个值就是我们自定义的拦截器的包全名+类名；3.解析plugin元素下的子元素，并将其包装为Properties对象；4.解析第二步拿到的数据，然后加载相应的类，并实例化一个对象出来（注意：这里用到了反射）；5.将第三步解析出来的Properties对象设置到第四步创建的Interceptor对象上；6.将第四步创建的Interceptor对象设置到Configuration对象的interceptorChain属性上（这个操作是通过调用Configuration类上的addInterceptor()方法完成的。这里还有一点需要注意：interceptorChain的类型为InterceptorChain，这让我想到了责任链及Spring的AOP和事务，有兴趣的可以翻看一下我之前梳理的与这两个主题有关的系列文章《Spring AOP系列》、《Spring事务系列》）。
关于上述解析步骤，个人觉得有以下几点需要注意：
- 上述第二步和第五步中都提到了Properties，为什么我们可以在plugin元素中使用property标签呢？为什么我们可以将这些值设置到Interceptor类型的对象上呢？这两个问题很好回答。关于第一个问题：因为MyBatis支持，如若不然，plugins元素的解析逻辑中不会出现Properties properties = child.getChildrenAsProperties()这样一行代码。那MyBatis是怎么支持的呢？这个就要看MyBatis配置文件的dtd约束文件了，先看下面这段从mybatis-3-config.dtd文件中摘抄出来的代码：<!ELEMENT plugin (property*)>。这段代码的大致意思就是说在plugin元素下可以有零个或多个property标签（具体参照下图“mybatis dtd文件关于plugin的定义”）。关于第二个问题：根据前面列出的源码，不难发现Interceptor源码中有一个default修饰的setProperties()方法，该方法返回值为void类型，默认不做任何处理。前面自定义的拦截器实现了这个方法。正因为Interceptor中有这样一个方法，所以解析代码中才有这样一句：interceptorInstance.setProperties(properties)。（也就是上面描述中的第五步）
- 上述第二步调用XMLConfigBuilder类的父类BaseBuilder类resolveClass()方法去解析我们在plugin元素中指定的interceptor属性值（包全名+拦截器名），该方法会继续调用BaseBuilder类中的resolveAlias()方法，这个方法会继续调用TypeAliasRegistry对象的resolveAlias()方法，这个方法的源码在上篇文章中已经展示过，这里就不再啰嗦，有兴趣可以翻看源码或者翻阅上篇文章。这段代码会直接将传递进来的string参数转为小写，然后从typeAliases中查找这个string参数代表的key是否存在，如果存在，则直接返回其对应的Class<?>类型的值，如果不存在，则直接使用Resources加载这个类。plugins的解析最终走的就是这一步
mybatis dtd文件关于plugin的定义
2 关于InterceptorChain的介绍
上小节的第六步中提到解析出来的Interceptor的对象会被设置到Configuration对象中的interceptorChain属性上。这个属性的实际类型为InterceptorChain。该类的源码为：
public class InterceptorChain {
private final List<Interceptor> interceptors = new ArrayList<>();
public Object pluginAll(Object target) {
for (Interceptor interceptor : interceptors) {
target = interceptor.plugin(target);
}
return target;
}
public void addInterceptor(Interceptor interceptor) {
interceptors.add(interceptor);
}
public List<Interceptor> getInterceptors() {
return Collections.unmodifiableList(interceptors);
}
}
这个类中定义了一个List类型的变量interceptors，其持有的类型为Interceptor，所以第六步调用Configuration类上的addInterceptor()方法，最终实际上调用的就是这个类上的addInterceptor()方法向interceptors变量中添加数据。这里面的pluginAll()方法是最终调度的入口。
