![](https://i-blog.csdnimg.cn/blog_migrate/2b04cc7fc8606a872f8d4b228026dc03.png)
1 .客户端初始化一个指向Servlet容器(例如Tomcat)的请求 ,即HttpServletRequest请求。
2 .这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助,例如:SiteMesh Plugin)
3. 接着FilterDispatcher被调用,FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action
4 .如果ActionMapper决定需要调用某个Action,FilterDispatcher把请求的处理交给ActionProxy
5 .ActionProxy通过Configuration Manager询问框架的配置文件,找到需要调用的Action类
6 .ActionProxy创建一个ActionInvocation的实例。
7 .ActionInvocation实例使用命名模式来调用,在调用Action的过程前后,涉及到相关拦截器(Intercepter)的调用。
8 .一旦Action执行完毕,ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是(但不总是,也可 能是另外的一个Action链)一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper
在上述过程中所有的对象(Action,Results,Interceptors,等)都是通过ObjectFactory来创建的。
Struts 2框架由3个部分组成:核心控制器FilterDispatcher、业务控制器和用户实现的业务逻辑组件。在这3个部分里,Struts 2框架提供了核心控制器FilterDispatcher(struts2.1.3之前,之后的推荐用StrutsPrepareAndExecuteFilter或者StrutsPrepareFilter和Strut***ecuteFilter),而用户需要实现业务控制器和业务逻辑组件。
2.核心控制器:FilterDispatcher
FilterDispatcher是Struts 2框架的核心控制器,该控制器作为一个Filter运行在Web应用中,它负责拦截所有的用户请求,当用户请求到达时,该Filter会过滤用户请求。如果用户请求以action结尾,该请求将被转入Struts 2框架处理。
Struts 2框架获得了*.action请求后,将根据*.action请求的前面部分决定调用哪个业务逻辑组件,例如,对于login.action请求,Struts 2调用名为login的Action来处理该请求。
Struts 2应用中的Action都被定义在struts.xml文件中,在该文件中定义Action时,定义了该Action的name属性和class属性,其中name属性决定了该Action处理哪个用户请求,而class属性决定了该Action的实现类。
Struts 2用于处理用户请求的Action实例,并不是用户实现的业务控制器,而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合,显然无法处理用户请求。而Struts 2框架提供了系列拦截器,该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来,传入到Action中,并回调Action 的execute方法来处理用户请求。
显然,上面的处理过程是典型的AOP(面向切面编程)处理方式。图3.19显示了这种处理模型。
![](https://i-blog.csdnimg.cn/blog_migrate/a019fdd56deac962743737b992697bb6.gif)
图3.19 Struts 2的拦截器和Action
从图3.19中可以看出,用户实现的Action类仅仅是Struts 2的Action代理的代理目标。用户实现的业务控制器(Action)则包含了对用户请求的处理。用户的请求数据包含在 HttpServletRequest对象里,而用户的Action类无需访问HttpServletRequest对象。拦截器负责将 HttpServletRequest里的请求数据解析出来,并传给业务逻辑组件Action实例。
3.业务控制器
正如从图3.19所看到的,业务控制器组件就是用户实现Action类的实例,Action类里通常包含了一个execute方法,该方法返回一个字符串——该字符串就是一个逻辑视图名,当业务控制器处理完用户请求后,根据处理结果不同,execute方法返回不同字符串 ——每个字符串对应一个视图名。
程序员开发出系统所需要的业务控制器后,还需要配置Struts 2的Action,即需要配置Action的如下三个部分定义:
— Action所处理的URL。
— Action组件所对应的实现类。
— Action里包含的逻辑视图和物理资源之间的对应关系。
每个Action都要处理一个用户请求,而用户请求总是包含了指定URL。当Filter Dispatcher拦截到用户请求后,根据请求的URL和Action处理URL之间的对应关系来处理转发。
4.Struts 2的模型组件
实际上,模型组件已经超出了MVC框架的覆盖范围。对于Struts 2框架而言,通常没有为模型组件的实现提供太多的帮助。
文本框: 图3.20 控制器调用模型组件Java EE应用里的模型组件,通常指系统的业务逻辑组件。而隐藏在系统的业务逻辑组件下面的,可能还包含了DAO、领域对象等组件。
通常,MVC框架里的业务控制器会调用模型组件的方法来处理用户请求。也就是说,业务逻辑控制器不会对用户请求进行任何实际处理,用户请求最终由模型组件负责处理。业务控制器只是中间负责调度的调度器,这也是称Action为控制器的原因。
![](https://i-blog.csdnimg.cn/blog_migrate/03ffb25fb740fd1a34113e34f514f021.gif)
图3.20显示了这种处理流程。
提示 在图3.20中看到Action调用业务逻辑组件的方法。当控制器需要获得业务逻辑组件实例时,通常并不会直接获取业务逻辑组件实例,而是通过工厂模式来获得业务逻辑组件的实例;或者利用其他IoC容器(如Spring容器)来管理业务逻辑组件的实例。
5.Struts 2的视图组件
Struts 2已经改变了Struts 1只能使用JSP作为视图技术的现状,Struts 2允许使用其他的模板技术,如FreeMarker、Velocity作为视图技术。
当Struts 2的控制器返回逻辑视图名时,逻辑视图并未与任何的视图技术关联,仅仅是返回一个字符串,该字符串作为逻辑视图名。
当我们在struts.xml文件中配置 Action时,不仅需要指定Action的name属性和class属性,还要为Action元素指定系列result子元素,每个result子元素定义一个逻辑视图和物理视图之间的映射。前面所介绍的应用都使用了JSP技术作为视图,故配置result子元素时没有指定type属性,默认使用JSP 作为视图资源。
如果需要在Struts 2中使用其他视图技术,则可以在配置result子元素时,指定相应的type属性即可。例如,如果需要使用FreeMarker,则为result指定值为freemarker的type属性;如果想使用Velocity模板技术作为视图资源,则为result指定值为velocity的type属性……
ActionFilter和其它过滤器
在web.xml配置这些Filter在Struts自身的Filter之前。 包括全局缺省的ActionFilter、语言编码LocaleFilter、重定向UrlRewriteFilter等等。
StrutsPrepareFilter
Struts的Action预处理过滤器。我的做法是写一个子类继承它,如CoreStrutsPrepareFilter,这样我可以在子类中实现诸如动态加载struts.xml和指定目录指定规则的struts-xxx.xml等。
StrutsExecuteFilter
同样是使用写子类继承它,如CoreStrutsExecuteFilter,写根据条件(如Struts相关的配置文件改动了)重新生成ExecuteOperations
(即Dispatcher的高级封装)。
Interceptor
拦截器是Struts2的精华。在这里处理包括异常统一处理、权限控制、参数设置、访问历史和某些特定功能的拦截式保存等处理。
Action
放置若干处理请求的指定包路径的方法,我设计了BaseAction和GenericAction,BaseAction处理全局的Action公共处理,包括继承ActionSupport,实现InitializingBean、ModelDriven(这样可以做一些初始化操作以及得到Struts2模型驱动的相关功能)。GenericAction是基于泛型来写的,实现了增删改查之类的公共方法。还有其它若干的项目相关的公共XXXAction,则根据需要设计。
Manager
在Action的Method中,可以调用若干个Manager方法来实现相关业务,事务是写在Manager层的,用的Spring的声明式事务。
ViewManager由于系统用的是Freemarker模板技术,所以解析模板的方式有两种:
1)通过Struts自带的FreemarkerManager;
2)通过FreeMarkerTemplateUtils来解析。为了方便扩展(比如写一些自定义的Freemarker方法等),我对两种方式都写了子类进行扩展。
CoreFreemarkerManager在struts.xml中配置:
<constant name="struts.freemarker.manager.classname" value="com.xxxx.framework.core.freemarker.CoreFreemarkerManager" />
CoreFreeMarkerTemplateUtils则就是一个工具类了。一般适用于CMS、邮件模板解析等。返回时经过的Interceptor
AOP的点也就是before和after,而after时的操作一般就是写日志了。
问题:
Struts 2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。
Spring的Ioc容器管理的bean默认是单实例的,上一次请求处理的状态信息被保持下来,并影响了下一次的请求,实际上就是Action中的类变量被不同的请求读取,出现错误结果
解决:就是不用单例, spring中bean的作用域设为prototype,每个请求对应一个实例.
1、Struts1
Struts1是单例模式,也就是所,Web容器(例如:Tomcat)启动的时候,就会实例化一个Action对象,那么所有请求都是用的这个对象。所以当遇到2个请求并发的时候,那么其实他们调用的是同一个类,这个时候当你在Action内部定义属性的时候,就会产生线程同步的问题。
例如:
你在Action定义了一个 int i = 0;
然后在这个Action里面的某一个方法里面对这个i进行操作。当并发的时候就会遇到问题。
所以:我们在用struts1的时候不能在action里面定义属性。要用到只的话只能在方法里面定义。
2、struts2
Struts 2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。所以我们可以在Struts2的Action里面去定义属性。但是Struts2由于 Action和普通的Java类没有任何区别(也就是不用像Struts1里面那样去实现一个Struts的接口,有兴趣的朋友可以自己去了解),所以我们可以用Spring去管理Struts2的Action,这个时候我们就要注意了,因为当我们在spring里面去定义bean的时候,spring默认用的是单例模式。所以在这个时候,你就要修改Spring的配置文件---即修改scope为prototype。
为什么struts1中并没有考虑到线程问题,因为所有的代码都是写在execute的方法中,所有变量都是定义在里面,所以没有线程安全问题。
而现在的struts2就不一样了。struts2的action中就像一个POJO一样,定义了很多的类变量。这就有线程安全问题了。。此时,就使用scope=prototype来指定是个原型模式,而不是单例,这样就解决了线程安全问题。每个线程都是一个新的实例。。
但是,线程同步是不得以的方法,是比较复杂的,而且会带来性能的损失。等效的代码中,不需要同步在编写容易度和性能上会更好些。
我这里强调的是什么代码是始终为线程安全的、是不需要同步的。如下:
1)常量始终是线程安全的,因为只存在读操作。
2)对构造器的访问(new 操作)是线程安全的,因为每次都新建一个实例,不会访问共享的资源。
3)最重要的是:局部变量是线程安全的。因为每执行一个方法,都会在独立的空间创建局部变量,它不是共享的资源。局部变量包括方法的参数变量。
struts user guide里有:
Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
译:只使用用局部变量。--编写线程安全的代码最重要的原则就是,在Action类中只使用局部变量,不使用实例变量。
这样的设计,从代码重构的角度来看,实际上是将一个复杂的系统,分而治之,从而使得每个部分的逻辑能够高度重用并具备高度可扩展性。所以,Interceptor结构实在是Struts2/Xwork设计中的精华之笔。
Struts2拦截器执行机理如下:
1. 整个结构就如同一个堆栈,除了Action以外,堆栈中的其他元素是Interceptor
2. Action位于堆栈的底部。由于堆栈"先进后出"的特性,如果我们试图把Action拿出来执行,我们必须首先把位于Action上端的Interceptor拿出来执行。这样,整个执行就形成了一个递归调用
3. 每个位于堆栈中的Interceptor,除了需要完成它自身的逻辑,还需要完成一个特殊的执行职责。这个执行职责有3种选择:
1) 中止整个执行,直接返回一个字符串作为resultCode
2) 通过递归调用负责调用堆栈中下一个Interceptor的执行
3) 如果在堆栈内已经不存在任何的Interceptor,调用Action