ActionContext 、Interceptor和ActionInvocation


Interceptor

拦截器参考http://www.doc88.com/p-742828789802.html，写的很好很详细

2、拦截器与过滤器的区别 ：

1. 拦截器是基于java的反射机制的，而过滤器是基于函数回调。

2. 拦截器不依赖与servlet容器，过滤器依赖与servlet容器。

3. 拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。

4. 拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。

5. 在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次

首先 是 ActionContext 类的源码：

public class ActionContext implements Serializable{
static ThreadLocal actionContext = new ThreadLocal();
public static final String ACTION_NAME = "com.opensymphony.xwork2.ActionContext.name";
public static final String VALUE_STACK = "com.opensymphony.xwork2.util.ValueStack.ValueStack";
public static final String SESSION = "com.opensymphony.xwork2.ActionContext.session";
public static final String APPLICATION = "com.opensymphony.xwork2.ActionContext.application";
public static final String PARAMETERS = "com.opensymphony.xwork2.ActionContext.parameters";
public static final String LOCALE = "com.opensymphony.xwork2.ActionContext.locale";
public static final String TYPE_CONVERTER = "com.opensymphony.xwork2.ActionContext.typeConverter";
public static final String ACTION_INVOCATION = "com.opensymphony.xwork2.ActionContext.actionInvocation";
public static final String CONVERSION_ERRORS = "com.opensymphony.xwork2.ActionContext.conversionErrors";
public static final String CONTAINER = "com.opensymphony.xwork2.ActionContext.container";
Map<String, Object> context;
public ActionContext(Map<String, Object> context)
{
this.context = context;
}
//... ...
public static void setContext(ActionContext context)
{
actionContext.set(context);
}
public static ActionContext getContext()
{
return (ActionContext)actionContext.get();
}
public void setContextMap(Map<String, Object> contextMap)
{
getContext().context = contextMap;
}
public Map<String, Object> getContextMap()
{
return this.context;
}
//... ...
public void setSession(Map<String, Object> session)
{
put("com.opensymphony.xwork2.ActionContext.session", session);
}
public Map<String, Object> getSession()
{
return (Map)get("com.opensymphony.xwork2.ActionContext.session");
}
//... ...
public Object get(String key)
{
return this.context.get(key);
}
public void put(String key, Object value)
{
this.context.put(key, value);
}
}

源码清晰的说明了我们编程中再熟悉不过的一行代码： ActionContext ctx = ActionContext.getContext();， 原来我们所取得的ctx来自于
ThreadLocal 啊！熟悉 ThreadLocal 的朋友都知道它是与当前线程绑定的，而且是我们Java中处理多线程问题的一种重要方式。我们再看，类中有个
Map 类型的变量 context ，其实，它才是前面我们提到的真正意义上的“容器”，用来存放 Action 在执行时所需要的那些数据。

到这里 ，他最初的那个问题已经很了然了。但是，他紧接着又一个疑惑提出来了：“那既然每个请求处理线程都有自己的 ActionContext ,那里面的那些数据是什么时候放进去的呢”？

这次 我给他的建议是，动脑筋，用源码验证。既然 ActionContext 存放有 HttpServletRequest 及其中的参数，既然
ActionContext 贯穿于整个请求处理过程，那就从struts2请求处理的入口(过滤器 StrutsPrepareAndExecuteFilter )找，源码：

public class StrutsPrepareAndExecuteFilter implements StrutsStatics, Filter
{
// ... ...
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException
{
HttpServletRequest request = (HttpServletRequest)req;
HttpServletResponse response = (HttpServletResponse)res;
try
{
this.prepare.setEncodingAndLocale(request, response);
this.prepare.createActionContext(request, response);//就是在这里进行创建并初始化ActionContext实例
this.prepare.assignDispatcherToThread();
if ((this.excludedPatterns != null) && (this.prepare.isUrlExcluded(request, this.excludedPatterns))) {
chain.doFilter(request, response);
} else {
request = this.prepare.wrapRequest(request);
ActionMapping mapping = this.prepare.findActionMapping(request, response, true);
if (mapping == null) {
boolean handled = this.execute.executeStaticResourceRequest(request, response);
if (!handled)
chain.doFilter(request, response);
}
else {
this.execute.executeAction(request, response, mapping);
}
}
} finally {
this.prepare.cleanupRequest(request);
}
}
//... ...
}

再找到 prepare 对应的类 PrepareOperations ，查看方法 createActionContext () ，就一目了然了。

interceptor说明

Interceptor的接口定义没有什么特别的地方，除了init和destory方法以外，intercept方法是实现整个拦截器机制的核心方法。而它所依赖的参数ActionInvocation则是我们之前章节中曾经提到过的著名的Action调度者。
我在这里需要指出的是一个很重要的方法invocation.invoke()。这是ActionInvocation中的方法，而ActionInvocation是Action调度者，所以这个方法具备以下2层含义(详细看DefaultActionInvocation源代码)：

1. 如果拦截器堆栈中还有其他的Interceptor，那么invocation.invoke()将调用堆栈中下一个Interceptor的执行。

2. 如果拦截器堆栈中只有Action了，那么invocation.invoke()将调用Action执行。

3.



DefaultActionInvocation部分源代码:
if (interceptors.hasNext()) {

final InterceptorMapping interceptor = (InterceptorMapping) interceptors.next();

UtilTimerStack.profile("interceptor: "+interceptor.getName(),

new UtilTimerStack.ProfilingBlock() {

public String doProfiling() throws Exception {

resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);//递归调用拦截器

return null;

}

});

} else {

resultCode = invokeActionOnly();

}
每个拦截器中的代码的执行顺序，在Action之前，拦截器的执行顺序与堆栈中定义的一致；而在Action和Result之后，拦截器的执行顺序与堆栈中定义的顺序相反。
Interceptor拦截类型

从上面的分析，我们知道，整个拦截器的核心部分是invocation.invoke()这个函数的调用位置。事实上，我们也正式根据这句代码的调用位置，来进行拦截类型的区分的。在Struts2中，Interceptor的拦截类型，分成以下三类：

1. before

before拦截，是指在拦截器中定义的代码，它们存在于invocation.invoke()代码执行之前。这些代码，将依照拦截器定义的顺序，顺序执行。

2. after

after拦截，是指在拦截器中定义的代码，它们存在于invocation.invoke()代码执行之后。这些代码，将一招拦截器定义的顺序，逆序执行。

PreResultListener

有的时候，before拦截和after拦截对我们来说是不够的，因为我们需要在Action执行完之后，但是还没有回到视图层之前，做一些事情。Struts2同样支持这样的拦截，这种拦截方式，是通过在拦截器中注册一个PreResultListener的接口来实现的。
如:在拦截器中使用如下代码,其中MyPreResultListener实现了PreResultListener 接口并在beforeResult方法中做了一些事情然后在拦截器类中加入action.addPreResultListener(new MyPreResultListener());

从源码中，我们可以看到，我们之前提到的Struts2的Action层的4个不同的层次，在这个方法中都有体现，他们分别是：拦截器（Interceptor）、Action、PreResultListener和Result。在这个方法中，保证了这些层次的有序调用和执行

问题
使用Struts2作为web框架，知道它的拦截器（Interceptor）机制，类似与Filter和Spring的AOP，于是实现了一个为Action增加自定义前置(before)动作和后置动作(after)的拦截器（曰：WInterceptor），不过用一段时间发现，在WInterceptor的after中，对Action对象的属性修改在页面看不到，对请求对象的属性设置也无效。为什么在调用了Action之后(invokeAction())之后，request就不能使用了呢，拦截器不能改变Action的Result么?
问题的关键在于，在调用actionInvocation.invoke()的之后，不仅执行类Action，也执行类Result。因而，等退回到拦截器的调用代码时，Result已经生成，View已经确定，这时你再修改模型（Action的属性）或请求对象的属性，对视图不会有任何影响。
解决办法:

方法一：使用现成的PreResultListener监听器事件

搞清楚原因，卷起袖子干吧，只要让WInterpretor的after事件，放在Result的生成之前就行了。
看看XWork的拦截器接口注入的actionInvocation，其实就提供增加Result执行的前置监听事件-PreResultListener：