语法标注解释
interceptor英音：[,int?'sept?]
在之前的文章中，我们已经涉及到了拦截器（Interceptor）的概念。 downpour 写道
拦截器是AOP中的概念，它本身是一段代码，可以通过定义“织入点”，来指定拦截器的代码在“织入点”的前后执行，从而起到拦截的作用。正如上面 Struts2的Reference中讲述的，Struts2的Interceptor，其拦截的对象是Action代码，可以定义在Action代码之前或者之后执行拦截器的代码。
接下来，我们将重点讨论一下Struts2中的拦截器的内部结构和执行顺序，并结合源码进行分析。 目 录 [ - ]
1. Interceptor结构 2. Interceptor执行分析 3. 源码解析
Interceptor结构
让我们再来回顾一下之前我们曾经用过的一张Action LifeCycle的图：
图中，我们可以发现，Struts2的Interceptor一层一层，把Action包裹在最里面。这样的结构，大概有以下一些特点：
1. 整个结构就如同一个堆栈，除了Action以外，堆栈中的其他元素是Interceptor
2. Action位于堆栈的底部。由于堆栈\先进后出\的特性，如果我们试图把Action拿出来执行，我们必须首先把位于Action上端的Interceptor拿出来执行。这样，整个执行就形成了一个递归调用
3. 每个位于堆栈中的Interceptor，除了需要完成它自身的逻辑，还需要完成一个特殊的执行职责。这个执行职责有3种选择：
1) 中止整个执行，直接返回一个字符串作为resultCode
2) 通过递归调用负责调用堆栈中下一个Interceptor的执行
3) 如果在堆栈内已经不存在任何的Interceptor，调用Action
Struts2的拦截器结构的设计，实际上是一个典型的责任链模式的应用。首先将整个执行划分成若干相同类型的元素，每个元素具备不同的逻辑责任，并将他们纳入到一个链式的数据结构中（我们可以把堆栈结构也看作是一个递归的链式结构），而每个元素又有责任负责链式结构中下一个元素的执行调用。
这样的设计，从代码重构的角度来看，实际上是将一个复杂的系统，分而治之，从而使得每个部分的逻辑能够高度重用并具备高度可扩展性。所以，Interceptor结构实在是Struts2/Xwork设计中的精华之笔。
Interceptor执行分析
Interceptor的定义
我们来看一下Interceptor的接口的定义： Java代码
1. public interface Interceptor extends Serializable { 2.
3. /**
4. * Called to let an interceptor clean up any resources it has allocated.
5. */
6. void destroy(); 7.
8. /**
9. * Called after an interceptor is created, but before any requests are processed using
10. * {@link #intercept(com.opensymphony.xwork2.ActionInvocation) intercept} , giving
11. * the Interceptor a chance to initialize any needed resources. 12. */
13. void init(); 14.
15. /**
16. * Allows the Interceptor to do some processing on the request before and/or after the rest of the processing of the 17. * request by the {@link ActionInvocation} or to short-circuit the processing and just return a String return code. 18. *
19. * @return the return code, either returned from {@link ActionInvocation#invoke()}, or from the interceptor itself.
20. * @throws Exception any system-level error, as defined in {@link com.opensymphony.xwork2.Action#execute()}. 21. */
22. String intercept(ActionInvocation invocation) throws Exception; 23.}
Interceptor的接口定义没有什么特别的地方，除了init和destory方法以外，intercept方法是实现整个拦截器机制的核心方法。而它所依赖的参数
ActionInvocation则是我们之前章节中曾经提到过的著名的Action调度者。
我们再来看看一个典型的Interceptor的抽象实现类： Java代码
1. public abstract class AroundInterceptor extends AbstractInterceptor { 2.
3. /* (non-Javadoc)
4. * @see com.opensymphony.xwork2.interceptor.AbstractInterceptor#intercept(com.opensymphony.xwork2.ActionInvocation)
5. */
6. @Override
7. public String intercept(ActionInvocation invocation) throws Exception {
8. String result = null; 9.
10. before(invocation);
11. // 调用下一个拦截器，如果拦截器不存在，则执行Action 12. result = invocation.invoke(); 13. after(invocation, result); 14.
15. return result; 16. } 17.
18. public abstract void before(ActionInvocation invocation) throws Exception; 19.
20. public abstract void after(ActionInvocation invocation, String resultCode) throws Exception; 21. 22.}
在这个实现类中，实际上已经实现了最简单的拦截器的雏形。或许大家对这样的代码还比较陌生，这没有关系。我在这里需要指出的是一个很重要的方法invocation.invoke()。这是ActionInvocation中的方法，而ActionInvocation是Action调度者，所以这个方法具备以下2层含义：
1. 如果拦截器堆栈中还有其他的Interceptor，那么invocation.invoke()将调用堆栈中下一个Interceptor的执行。
2. 如果拦截器堆栈中只有Action了，那么invocation.invoke()将调用Action执行。
所以，我们可以发现，invocation.invoke()这个方法其实是整个拦截器框架的实现核心。基于这样的实现机制，我们还可以得到下面2个非常重要的推论：
1. 如果在拦截器中，我们不使用invocation.invoke()来完成堆栈中下一个元素的调用，而是直接返回一个字符串作为执行结果，那么整个执行将被中止。
2. 我们可以以invocation.invoke()为界，将拦截器中的代码分成2个部分，在invocation.invoke()之前的代码，将会在Action之前被依次执行，而在invocation.invoke()之后的代码，将会在Action之后被逆序执行。