Struts2的运行流程

根据一个简单的登录分析Struts2的运行流程：

1)   首先是在登录页面，用户填入账号和密码， 然后单击提交按钮， 好了， 就从这里开始分析背后的处理流程，这是我们进行分析的起点。

2)   当用户提交登录请求后，请求会被Tomcat 服务器接收到， Tomcat 服务器会根据请求URL 中的web 上下文，来选择处理这个请求的Web 应用。

3)   Web 容器会去读取对应工程的web.xml， 在web.xm l 中进行匹配，发现扩展名为.action 的请求， 由Struts 2 这个过滤器来进行处理，根据Filter 的配置，找到实际的类为FiIterDispatcher。

4)   Web 容器会获取FilterDispatcher 这个类的实例， 然后回调doFilter 方法，进行真正的处理。FilterDispatcher 作为前端控制器，是整个Struts 2 的调度中心.

5)   FilterDispatcher 将请求转发给ActionMapper。ActionMapper 负责识别当前的请求是否需要Struts 2 做出处理。

6)   ActionMapper 告诉FiActionProxy 拿到了运行哪个Action、相关的拦截器以及所有可能使用的

7)   result 信息，就可以着手建立Actionlnvocation 对象了， Actionlnvocation 对象描述了

8)   Action 运行的整个过程。lterDispatcher ， 需要处理这个请求， FilterDispatcher会停止过滤器链以后的部分， 所以通常情况下: FilterDispatcher 应该出现在过滤器链的最后。

9)   然后建立一个ActionProxy 对象，这个对象作为Action 与xwork 之间的中间层，会代理Action 的运行过程。

10) ActionProxy 对象刚被创建出来的时候， 并不知道要运行哪个Action ，它手里只有从FilterDispatcher 中拿到的请求的URL。这时候，它去向ConfigurationManager询问到底要运行哪个Action 。

11) 回忆一下. HelloWorld 中Action 的execute 方法运行的时候， 是不是它的属性就已经有了请求中的参数呢?这说明， 在execute 方法之前， 有人偷偷地帮我们做了这件事， 把请求中的参数赋值到了Action 的属性上， 这个" 人"就是刚刚说的拦截器。

拦截器的运行被分成两部分， 一部分在Action 之前运行， 一部分在Result 之后运行， 而且顺序是刚好反过来的。也就是在Action 执行前的顺序，比如是拦截器1 、拦截器2、拦截器3. 那么运行Result 之后，再次运行拦截器的时候，顺序就变成拦截器3 、拦截器2 、拦截器1了。总之， ActionInvocation 对象执行的时候比较复杂，会做很多事：

a)   首先按照拦截器的引用顺序依次执行各个拦截器的前置部分。

b)   然后执行Action 的execute 方法。

c)   然后根据execute 方法返回的结果，也就是Result，在struts.xml 中匹配选择下一个页面。

d)   找到页面后， 由于现在的页面一般都是模板页面，在页面上，可以通过Struts2 自带的标签库来访问需要的数据，并生成最终页面.

e)   最后， Actionlnvocation 对象再按照拦截器的寻找用顺序的倒序依次执行各个拦截器的后置部分。

f)   ActionInvocation 对象执行完毕后，实际上就已经得到响应对象了，也就

g)   是HttpServ1etResponse 对象，最后按与过滤器器配置定义相反的顺序依次经过过滤器，向用户展示出响应的结果。