【struts2】Struts2的运行流程

　　1）前提条件

　　在讲解流程之前，假设我们已经建立了的一个名为strutsDeepen的web工程，该工程仅仅实现了简单的用户登陆与欢迎界面。具体的实现为：

在web.xml中配置了Struts2的过滤器
写了一个Action类，名称为loginAction
在struts.xml中配置了这个Action类
写了两个页面，一个是登录页面，一个是欢迎页面

　　只做了这么点事情，就可以在Struts2的帮助下顺利完成功能调用，那么Struts2内部是怎么运行的呢？逐步来根据系统架构图进行分析。

　　2）运行流程

当用户提交登录请求后，请求的URL为：“/strutsDeepen/loginAction.action”，请求会被Tomcat服务器接收到，Tomcat服务器会根据请求URL中的web上下文，也就是“/strutsDeepen”，来选择处理这个请求的Web应用，那就是由strutsDeepen这个web工程来处理这个请求。
Web容器会去读取strutsDeepen这个工程的web.xml，在web.xml中进行匹配，发现后缀为“.action”的请求，由struts2这个过滤器来进行处理，根据Filter的配置，找到实际的类为FilterDispatcher。
Web容器会获取FilterDispatcher这个类的实例，然后回调doFilter方法，进行真正的处理。FilterDispatcher作为前端控制器，是整个Struts2的调度中心。

注意：在架构图上，可以看到有三个过滤器层次，分别是ActionContextCleanUp、SiteMesh等其他过滤器和FilterDispatcher。这三个层次中，ActionContextCleanUp和FilterDispatcher是Struts2的过滤器，而SiteMeshSiteMesh等其他过滤器不是。

FilterDispatcher是任何一个Struts2应用都需要配置的，一般出现在过滤器链的最后；如果在FilterDispatcher前出现了如SiteMesh这种特殊的过滤器，还必须在SiteMesh前引用Struts2的ActionContextCleanUp过滤器。

在前面的strutsDeepen中，并没有出现SiteMesh这种特殊的过滤器，所以只需要引用FilterDispatcher就可以了。
FilterDispatcher将请求转发给ActionMapper。ActionMapper负责识别当前的请求是否需要Struts2做出处理。
ActionMapper告诉FilterDispatcher，需要处理这个请求，FilterDispatcher会停止过滤器链以后的部分，所以通常情况下：FilterDispatcher应该出现在过滤器链的最后。然后建立一个ActionProxy对象，这个对象作为Action与xwork之间的中间层，会代理Action的运行过程。
ActionProxy对象刚被创建出来的时候，并不知道要运行哪个Action，它手里只有从FilterDispatcher中拿到的请求的URL。这时候，它去向ConfigurationManager询问到底要运行哪个Action。某个特定的URL由哪个Action响应由谁负责，定义在什么地方呢？没错，在struts.xml里面。而ConfigurationManager就是负责读取并管理struts.xml的，可以简单的理解为ConfigurationManager是struts.xml在内存中的映像。在服务器启动的时候，ConfigurationManager会一次性的把struts.xml中的所有信息读到内存里，并缓存起来，以保证ActionProxy拿着来访的URL向他询问要运行哪个Action的时候，就可以直接匹配、查找并回答了。
ActionProxy拿到了运行哪个Action、相关的拦截器以及所有可能使用的result信息，就可以着手建立ActionInvocation对象了，ActionInvocation对象描述了Action运行的整个过程。

注意：Action运行绝不仅仅只是运行Action的execute方法这么简单，还包括其他部分，完整的调用过程由ActionInvocation对象负责。
回忆一下，strutsDeepen中Action的execute方法运行的时候，是不是它的属性就已经有了请求中的参数呢？这说明，在execute方法之前，有人偷偷的帮我们做了这件事，把请求中的参数赋值到了Action的属性上，这个“有人”就是刚刚说的拦截器。拦截器的运行被分成两部分，一部分在Action之前运行，一部分在Result之后运行，而且顺序是刚好反过来的。也就是在Action执行前的顺序，比如是拦截器1、拦截器2、拦截器3，那么运行Result之后，再次运行拦截器的时候，顺序就变成拦截器3、拦截器2、拦截器1了。
总之ActionInvocation对象执行的时候比较复杂，会做很多事：
- 首先，按照拦截器的引用顺序依次执行各个拦截器的前置部分；
- 然后，执行Action的execute方法；
- 然后，根据execute方法返回的结果，也就是Result，在struts.xml中匹配选择下一个页面；
- 找到页面后，由于现在的页面一般都是模板页面，在页面上，可以通过Struts2自带的标签库来访问需要的数据，并生成最终页面；
- 最后，ActionInvocation对象再按照拦截器的引用顺序的倒序依次执行各个拦截器的后置部分。
ActionInvocation对象执行完毕后，实际上就已经得到响应对象了，也就是HttpServletResponse对象，最后按与过滤器器配置定义相反的顺序依次经过过滤器，向用户展示出响应的结果。