02-Struts2的工作流程及配置文件.doc

Struts2的工作流程及配置文件 Struts2.0的流程图 从图中看到Struts2的工作流程如下： 1.服务器接收到的请求首先经过一组过滤器链（实际中的其他过滤器可能还包括诸如Spring的字符过滤器CharactorEncodingFilter、Velocity的过滤器等，一般FilterDispatcher位于过滤器的最后一个执行），过滤器链按照你在web.xml中的配置顺序在接收客户请求时顺序执行，在向客户发送响应时反序执行，Struts2的核心FilterDispatcher在web.xml中的配置如下： filter filter-namesetCharactor/filter-name !-- 配置字符过滤 -- filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter filter-namestruts2/filter-name !-- 配置Struts2过滤器 -- filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter-mapping filter-namesetCharactor/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts2/filter-name url-pattern/*/url-pattern /filter-mapping 注意：如果你使用的是WebLogic6.1作为应用服务器，需要使用FilterDispatcherCompatWeblogic61替代FilterDispatcher。 2.请求被送到FilterDispatcher之后，FilterDispatcher会通过其私有静态的属性ActionMapper询问这个请求是否需要调用Action处理，如果需要调用Action，FilterDispatcher会把请求委托给ActionProxy，ActionProxy调用ActionInvocation查找配置文件中该Action的所有信息，并以这个Action为目标创建代理对象（因为Struts2中的Action由于XWork的设计理念，并没有与Servlet的API被调用，所以如果直接调用Action的实例，那么显然基于HTTP的请求都将无法传入Action。Struts2通过创建Action的代理对象，并使用拦截器将HTTP的请求信息传入代理对象，这是典型的AOP处理方式，这也实现了控制器与Servlet的API的分离，这是Struts1.x所欠缺的优秀的设计方式），然后执行该Action之前的所配置的所有拦截器，与过滤器相同，在接受请求时，会顺序执行你在配置文件中为该Action配置的拦截器顺序； 3.在穿越拦截器之后，就会执行Action，当Action执行完毕，ActionInvocation就要使用result加载结果（可以是JSP、PDF、XML、Velocity、EXCEL、Action等，Struts2为我们提供了丰富的视图模板可以调用），加载完结果之后会再次反向穿越拦截器和过滤器链，将响应结果发送给客户； 从上面不难看出，拦截器（Interceptor）是Struts2中非常重要的组成部分，在Struts2中绝大多数功能都是通过配置拦截器实现的，例如防止表单的重复提交、文件上传等等。 在上图中的action与Struts1有很大的不同，Struts1在接收到第一个请求时，会创建Action实例，将其放到HashMap中，以后的请求会直接返回这个实例，也就是说一个Action的实例是多线程共享的，这样虽然节省了资源，但在Action中应谨慎使用全局变量，因为全局变量是多线程共享的，所以Struts1+Hibernate3+Spring2整合的时候，其中一种方式是把Struts1的Action交给Spring容器管理，我们在Spring的XML文件中用bean元素配置Action的时候，Spring建议我们设置singleton=”false”（Spring2.0之后改为scope=”prototype”），也就是一个请求产生一个Action实例！ 在