struts2机制

（转自朋友给的word文档，真正的作者不知道呀）

上图来源于Struts2官方站点，是Struts 2 的整体结构

(1)一个请求在Struts2框架中的处理大概分为以下几个步骤 
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来创建的。

 

1.Struts 2的基本流程 
  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显示了这种处理模型。 



图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为控制器的原因。 



图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时的操作一般就是写日志了。

 

 

struts2线程安全 

问题：
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类中只使用局部变量，不使用实例变量。

 

struts2中的责任链模式 

在 面向对象设计里, 责任链模式是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

 

而在Struts2中，其拦截器结构的设计，是一个典型的责任链模式的应用。首先将整个执行划分成若干相同类型的元素，每个元素具备不同的逻辑责任，并将他们纳入到一个链式的数据结构中（我们可以把堆栈结构也看作是一个递归的链式结构），而每个元素又有责任负责链式结构中下一个元素的执行调用。 

这样的设计，从代码重构的角度来看，实际上是将一个复杂的系统，分而治之，从而使得每个部分的逻辑能够高度重用并具备高度可扩展性。所以，Interceptor结构实在是Struts2/Xwork设计中的精华之笔。 
Struts2拦截器执行机理如下： 
1. 整个结构就如同一个堆栈，除了Action以外，堆栈中的其他元素是Interceptor 

2. Action位于堆栈的底部。由于堆栈"先进后出"的特性，如果我们试图把Action拿出来执行，我们必须首先把位于Action上端的Interceptor拿出来执行。这样，整个执行就形成了一个递归调用 

3. 每个位于堆栈中的Interceptor，除了需要完成它自身的逻辑，还需要完成一个特殊的执行职责。这个执行职责有3种选择： 

1) 中止整个执行，直接返回一个字符串作为resultCode 

2) 通过递归调用负责调用堆栈中下一个Interceptor的执行 

3) 如果在堆栈内已经不存在任何的Interceptor，调用Action