Struts2

Action的定义

传统的MVC框架中，Control层一般都是一个类似与Servlet的一个Java对象。因为从职责上讲，Control层需要完成以下的职责：

1. 接收从Web容器传递过来的参数，并做恰当的类型转化

2. 调用逻辑处理

3. 搜集数据，并返回到视图

而在这个其中的第一步和第三步，都离不开Web容器中的对象的处理。

Struts2中的Action，与其他传统的MVC框架不同，使用了XWork的Action来构造Control层。让我们首先来看看Action的接口定义：

Java代码
  1. /**  
  2.  * All actions may implement this interface, which exposes  
  3.  * the execute() method. However, as of XWork 1.1, this is  
  4.  * not required and is only here to assist users. You are  
  5.  * free to create POJOs that honor the same contract  
  6.  * defined by this interface without actually implementing  
  7.  * the interface.  
  8.  */  
  9. public interface Action {   
  10.   
  11.     /**  
  12.      * Where the logic of the action is executed.  
  13.      *  
  14.      * @return a string representing the logical result of the execution.  
  15.      *         See constants in this interface for a list of standard result values.  
  16.      * @throws Exception thrown if a system level exception occurs.  
  17.      *                   Application level exceptions should be handled by returning  
  18.      *                   an error value, such as Action.ERROR.  
  19.      */  
  20.     public String execute() throws Exception;   
  21. }  


我们只需要实现这个接口，就可以在其中编写业务逻辑完成我们的功能。

Java代码
  1. public class Index implements Action {   
  2.   
  3.     private static final long serialVersionUID = -1070481751569420550L;   
  4.   
  5.     /* (non-Javadoc)  
  6.      * @see com.opensymphony.xwork2.Action#execute()  
  7.      */  
  8.     public String execute() throws Exception {   
  9.         // write your logic here   
  10.         return SUCCESS;   
  11.     }   
  12. }  


在这个接口定义中，我们可以明显看到与传统的MVC框架之间的区别：Struts2中的Action，并不需要依赖于特定的Web容器。我们看不到类似HttpServletRequest，HttpServletResponse等Web容器相关的对象。

而这一点，也带来了问题：

提问：Struts2的Action并不带有任何Web容器相关的对象，Action又是如何工作在Web容器中的呢？

虽然Struts2的Action只是一个非常普通的Java对象，并不具备任何Web容器的特质，但是我们需要把Action放到一个更加大的环境中来看。事实上，Struts2为Action的执行，准备了完整的数据环境和执行环境。而这个执行环境，就保证了Action在Web容器中的顺利运行。

在Struts2中，每个Http的请求，会被发送到一个Filter。而这个Filter，就会针对每个请求，创建出一个代码的执行环境，并在这个基础上，为每个执行环境配备与之对应的数据环境，这个数据环境中的内容，就来自于Web容器中的一个又一个对象。这样，就能够顺利调用Action执行代码而无需担心它是否运行在Web容器中了。

至于这个执行环境和数据环境到底是什么，我们接下来会详细讲到。

提问：Struts2的Action并不带有任何Web容器相关的对象，Action中又如何与Web容器进行通信并获取Web容器的相关对象呢？

刚刚我们提到Struts2会为每个Http的请求建立一个执行环境和数据环境。其中，数据环境就成为了Action获取Web容器的基础。所以，当Action需要获取Web容器的相关对象，需要通过数据环境来进行。


Struts2的Action的这一个重要特性，至少能为我们带来以下好处：

1. 使得Struts2的Action非常易于测试

如果我们完全不考虑Action的执行环境，仅仅把Action看作一个普通的Java对象，那么我们甚至可以直接new一个Action的对象，通过执行其中的方法完成测试。这样，我们就不需要任何的Mock，来模拟Web容器的环境。

2. 结合Action的执行环境，使得Struts2在Control这个层次上，能够定义更加丰富的执行层次

因为Action是一个普通的Java类，而不是一个Servlet类，完全脱离于Web容器，所以我们就能够更加方便地对Control层进行合理的层次设计，从而抽象出许多公共的逻辑，并将这些逻辑脱离出Action对象本身。事实上，Struts2也正是这么做的，无论是Interceptor，还是Result，其实都是抽象出了Action中公共的逻辑部分，将他们放到了Action的外面，从而更加简化了Action的开发。

3. 使得Struts2的Action看上去更像一个POJO，从而更加易于管理

Struts2的Action是一个线程安全的对象。而Web容器传递过来的参数，也会传递到Action中的成员变量中。这样，Action看上去就更像一个POJO，从而能够方便的被许多对象容器进行管理。比如说，你可以非常方便得把Action纳入到Spring的容器中进行管理。

Action的生命周期

接下来，我们再来看看Struts2中的Action的生命周期：



这张图来自于Struts2的Reference，我们能够在图中看到许多我们不熟悉的名词，比如ActionProxy，Interceptor等等。这些都是Struts2的Control层的重要元素，也是Struts2的Control层的一个层次化的体现。

上面的这张图基本上能够概括了Struts2的整个生命周期。接下来，我们就对Action中的一些重要元素进行简单的描述。

Action的五大元素

在大概了解了Struts2的Action后，我们来重点研究一下在Struts2的Action周围，为Action进行服务的一些重要元素，这些元素将涵盖Action的数据环境，Action的执行环境、Action的调度者、Action的层次结构和Action的执行结果。

ActionContext —— 数据环境

之前我们提到了Struts2的Action并不是一个Servlet，它是脱离了Web容器的。但是对于一个Web框架来说，所有的数据请求（Request）和数据返回（Response）都来源于Web容器，那么Action在执行的时候，如何去获取这些数据呢？

这个问题的答案就在于，我们需要为每个Action准备一个数据环境，这个数据环境被称之为：ActionContext。由于Action是应对于一个又一个的URL请求，所以ActionContext应该具备以下的特性：

1. ActionContext应成为Action与Web容器之间的桥梁

2. ActionContext中应该保存有针对某个请求的详细信息

3. ActionContext应该是一个线程安全的类对象

Interceptor —— 丰富的层次结构

简单回顾一下上面所提到的Action的职责，我们看到，需要在Action这个层面上完成的事情还不少。而完成这些职责，就需要我们对这些职责进行合理的分类和排序，将他们组织成有序的执行队列。在Struts2中，使用了一种类似责任链的设计模式对这些不同的职责进行分类并串联起来，从而使得Action层具备了丰富的层次结构。而在这个执行队列中的每个元素，就被我们称之为Interceptor，也就是拦截器。

Struts2 Reference 写道
Interceptors can execute code before and after an Action is invoked.


拦截器是AOP中的概念，它本身是一段代码，可以通过定义“织入点”，来指定拦截器的代码在“织入点”的前后执行，从而起到拦截的作用。正如上面Struts2的Reference中讲述的，Struts2的Interceptor，其拦截的对象是Action代码，可以定义在Action代码之前或者之后执行拦截器的代码。

如果仔细留意一下Action LifeCycle图中的Interceptor和Action的部分，我们可以看到，Interceptor一层一层的把Action包了起来。这是一个典型的堆栈结构，在代码执行的时候，每个Interceptor不仅需要文成它自身的逻辑，还通过递归调用负责下一个拦截器或Action的调用。

Struts2 Reference 写道
Most of the framework's core functionality is implemented as Interceptors. Features like double-submit guards, type conversion, object population, validation, file upload, page preparation, and more, are all implemented with the help of Interceptors. Each and every Interceptor is pluggable, so you can decide exactly which features an Action needs to support.


也正如Struts2的Reference所说，Struts2提供的绝大多数的功能支持，都通过Interceptor来实现，这些Interceptor可以随意进行配置，并且能够方便的插入到程序中去运行。

Result —— 执行结果

有执行就必然有执行的结果。在Struts2中，Action的执行结果被抽象成了一个层次。在这个层次中，可以定义任意类型的View层的结构。也就是说，Struts2并不强制View层的表现形式，可以是JSP、Freemarker模板、二进制流输出等等。

Struts2把执行结果抽象成一个层次，使得你可以不再关注许多视图整合上面的细节，只需要考虑视图的类型和数据的准备，这样，你也可以不必在沉浸在杂乱的构造视图的代码中。

ActionProxy —— 执行环境

有了拦截器Interceptor，有了Action本身，也有了Action的执行结果Result，我们就需要一个类似调度器的产品，将这些元素整合起来，进行调度执行。在上面的Action Lifecyle的图中，我们可以看到，Interceptor、Action和Result都处于ActionProxy中，所以ActionProxy就成为了所有这些元素的执行环境。


既然是执行环境，那么ActionProxy就需要提供Action执行的时候一切所需要的配置、参数等等，当然，也要有进行Action调用的入口。所以让我们来看一下ActionProxy的接口：

Java代码
  1. public interface ActionProxy {   
  2.   
  3.     /**  
  4.      * Called after all dependencies are set  
  5.      */  
  6.     void prepare() throws Exception;   
  7.        
  8.     /**  
  9.      * @return the Action instance for this Proxy  
  10.      */  
  11.     Object getAction();   
  12.   
  13.     /**  
  14.      * @return the alias name this ActionProxy is mapped to  
  15.      */  
  16.     String getActionName();   
  17.   
  18.     /**  
  19.      * @return the ActionConfig this ActionProxy is built from  
  20.      */  
  21.     ActionConfig getConfig();   
  22.   
  23.     /**  
  24.      * Sets whether this ActionProxy should also execute the Result after executing the Action  
  25.      *  
  26.      * @param executeResult  
  27.      */  
  28.     void setExecuteResult(boolean executeResult);   
  29.   
  30.     /**  
  31.      * @return the status of whether the ActionProxy is set to execute the Result after the Action is executed  
  32.      */  
  33.     boolean getExecuteResult();   
  34.   
  35.     /**  
  36.      * @return the ActionInvocation associated with this ActionProxy  
  37.      */  
  38.     ActionInvocation getInvocation();   
  39.   
  40.     /**  
  41.      * @return the namespace the ActionConfig for this ActionProxy is mapped to  
  42.      */  
  43.     String getNamespace();   
  44.   
  45.     /**  
  46.      * Execute this ActionProxy. This will set the ActionContext from the ActionInvocation into the ActionContext  
  47.      * ThreadLocal before invoking the ActionInvocation, then set the old ActionContext back into the ThreadLocal.  
  48.      *  
  49.      * @return the result code returned from executing the ActionInvocation  
  50.      * @throws Exception  
  51.      * @see ActionInvocation  
  52.      */  
  53.     String execute() throws Exception;   
  54.   
  55.     /**  
  56.      * Sets the method to execute for the action invocation. If no method is specified, the method provided by  
  57.      * in the action's configuration will be used.  
  58.      *  
  59.      * @param method the string name of the method to invoke  
  60.      */  
  61.     void setMethod(String method);   
  62.   
  63.     /**  
  64.      * Returns the method to execute, or null if no method has been specified (meaning "execute" will be invoked)  
  65.      */  
  66.     String getMethod();   
  67.        
  68. }  


很显然，在这其中，prepare和execute方法是用作Action调用的入口函数，其他的接口定义都与Action执行时的运行参数和配置有关。

ActionInvocation —— 调度者

在上面的ActionProxy的接口定义中，我们可以看到有一个比较特殊的变量：ActionInvocation比较吸引我们的眼球。从字面上去理解，ActionInvocation就是Action的调用者。事实上也是如此，ActionInvocation在这个Action的执行过程中，负责Interceptor、Action和Result等一系列元素的调度。

在之后的章节中，这个ActionInvocation类也将成为我们解读Struts2源码的一个重要入手点。这个类将告诉你，Struts2是如何通过ActionInvocation来实现对Interceptor、Action和Result的合理调度的。

拦截器详解:http://www.javaeye.com/wiki/struts2/1397-deep-into-struts2-interceptors
Result机制，让视图更丰富:http://www.javaeye.com/wiki/struts2/1462-result-in-struts2
WebWork2多模块解决方法: http://www.javaeye.com/topic/6529
============================================================================================================
Struts2配置详解
Struts2的配置文件是以XML的形式出现的。不过它的XML的语义比较简单，下面是我抽取了位于struts2-core-2.0.14.jar内部的struts-default.xml的片段：

Xml代码
  1. <struts>  
  2.     <bean class="com.opensymphony.xwork2.ObjectFactory" name="xwork" />  
  3.     <bean type="com.opensymphony.xwork2.ObjectFactory" name="struts" class="org.apache.struts2.impl.StrutsObjectFactory" />  
  4.   
  5.     <bean type="com.opensymphony.xwork2.ActionProxyFactory" name="xwork" class="com.opensymphony.xwork2.DefaultActionProxyFactory"/>  
  6.     <bean type="com.opensymphony.xwork2.ActionProxyFactory" name="struts" class="org.apache.struts2.impl.StrutsActionProxyFactory"/>  
  7.        
  8.     <!-- 省略了其他的bean节点的定义 -->  
  9.   
  10.     <!--  Only have static injections -->  
  11.     <bean class="com.opensymphony.xwork2.ObjectFactory" static="true" />  
  12.     <bean class="com.opensymphony.xwork2.util.XWorkConverter" static="true" />  
  13.        
  14.      <!-- 省略了其他的静态注入的定义 -->  
  15.      
  16.     <package name="struts-default" abstract="true">  
  17.         <result-types>  
  18.             <result-type name="chain" class="com.opensymphony.xwork2.ActionChainResult"/>  
  19.             <result-type name="dispatcher" class="org.apache.struts2.dispatcher.ServletDispatcherResult" default="true"/>  
  20.             <result-type name="redirect" class="org.apache.struts2.dispatcher.ServletRedirectResult"/>  
  21.   
  22.             <!-- 省略了其他的ResultType的定义 -->  
  23.     
  24.         </result-types>  
  25.   
  26.         <interceptors>  
  27.             <interceptor name="autowiring" class="com.opensymphony.xwork2.spring.interceptor.ActionAutowiringInterceptor"/>  
  28.             <interceptor name="params" class="com.opensymphony.xwork2.interceptor.ParametersInterceptor"/>  
  29.   
  30.             <!-- 省略了其他的Interceptor的定义 -->  
  31.   
  32.             <!-- Basic stack -->  
  33.             <interceptor-stack name="basicStack">  
  34.                 <interceptor-ref name="exception"/>  
  35.                 <interceptor-ref name="servletConfig"/>  
  36.                 <interceptor-ref name="prepare"/>  
  37.                 <interceptor-ref name="checkbox"/>  
  38.                 <interceptor-ref name="params"/>  
  39.                 <interceptor-ref name="conversionError"/>  
  40.             </interceptor-stack>  
  41.   
  42.             <!-- A complete stack with all the common interceptors in place.   
  43.                  Generally, this stack should be the one you use, though it   
  44.                  may do more than you need. Also, the ordering can be   
  45.                  switched around (ex: if you wish to have your servlet-related   
  46.                  objects applied before prepare() is called, you'd need to move   
  47.                  servlet-config interceptor up.   
  48.   
  49.                  This stack also excludes from the normal validation and workflow   
  50.                  the method names input, back, and cancel. These typically are   
  51.                  associated with requests that should not be validated.   
  52.                  -->  
  53.             <interceptor-stack name="defaultStack">  
  54.                 <interceptor-ref name="exception"/>  
  55.                 <interceptor-ref name="alias"/>  
  56.                 <interceptor-ref name="servletConfig"/>  
  57.                 <interceptor-ref name="prepare"/>  
  58.                 <interceptor-ref name="i18n"/>  
  59.                 <interceptor-ref name="chain"/>  
  60.                 <interceptor-ref name="debugging"/>  
  61.                 <interceptor-ref name="profiling"/>  
  62.                 <interceptor-ref name="scopedModelDriven"/>  
  63.                 <interceptor-ref name="modelDriven"/>  
  64.                 <interceptor-ref name="fileUpload"/>  
  65.                 <interceptor-ref name="checkbox"/>  
  66.                 <interceptor-ref name="staticParams"/>  
  67.                 <interceptor-ref name="params">  
  68.                   <param name="excludeParams">dojo\..*</param>  
  69.                 </interceptor-ref>  
  70.                 <interceptor-ref name="conversionError"/>  
  71.                 <interceptor-ref name="validation">  
  72.                     <param name="excludeMethods">input,back,cancel,browse</param>  
  73.                 </interceptor-ref>  
  74.                 <interceptor-ref name="workflow">  
  75.                     <param name="excludeMethods">input,back,cancel,browse</param>  
  76.                 </interceptor-ref>  
  77.             </interceptor-stack>  
  78.   
  79.             <!-- 省略了其他的interceptor-stack节点的定义 -->  
  80.   
  81.        </interceptors>  
  82.   
  83.         <default-interceptor-ref name="defaultStack"/>  
  84.   
  85.     </package>  
  86.   
  87. </struts>  


在这个配置文件中，我们可以看到，Struts2的XML自身所支持的节点和子节点并不是很多，大致来说，这些节点可以分成基本配置定义和Runtime配置定义。

基本配置定义

基本配置定义，主要是针对在Struts2内部所使用的各种元素的声明。这些声明往往规定了Struts2内部的一些行为特征。

例如，配置文件中的<bean>节点，被用于定义Struts2中所使用的接口和实现类，通过Struts2内部实现的IoC，你就可以在不同的实现类之间进行切换。

再例如，配置文件中的<result-type>节点和<interceptor>节点。他们用于定义Struts2中所支持的所有的Result类型和拦截器，这些定义和声明，将在Runtime的配置定义中被引用。

我之所以把配置文件中的这些节点单独列出来，作为一个种类，是因为这些节点是不可省略的，也是无法简化的。所以，如果我们试图在Struts2中简化配置，我们就需要在Runtime配置定义中下功夫，而这些基本配置定义，我们可以认为是Runtime配置定义的基础。

Runtime配置定义

Runtime配置定义，主要指的的是对Struts2运行过程中，具体的某个Action的行为的指定。这些指定主要通过<package>节点中的<action>节点来完成。

仔细翻阅<action>节点，我们可以发现，它是URL与Action之间沟通的桥梁，也就是说，它定义了URL与Action之间的对应关系。同时，它还指定了Action在执行过程中的具体行为，包括Action执行的时候使用什么样的拦截器、Action执行完毕后，转向到什么样的Result等等。

Runtime配置定义是可以简化的，Struts2中提供了很多种简化配置的方式，这个在之后的文章中会详细提到。

模块化管理配置文件

一旦项目变得很大，项目中同时也并不采取什么简化配置的措施，那么在默认情况下，配置文件就会变得很大而不易于维护。这个时候，对于配置文件的模块化管理的需求就显现出来。Struts2提供了两种方式对配置文件进行模块化管理。

plugin机制

Struts2有plugin的机制，有关plugin的具体的知识，请参考我的另外一篇专栏文章：《深入plugin》 ——  http://www.javaeye.com/wiki/struts2/1333-deep-into-plugin。在这里，我也就不详细介绍了。

在每个plugin中，都会有一个叫做struts-plugin.xml的配置文件，这个配置文件的格式与struts-default.xml的格式是相同的。可以在其中做出任何的Struts2的定义和配置。我们知道，Struts2的配置文件的加载顺序，是按照以下的顺序来：

Struts2 Referece 写道
1. struts-default.xml (bundled in the Core JAR)
2. struts-plugin.xml (as many as can be found in other JARs)
3. struts.xml (provided by your application)


所以，struts-plugin.xml中的配置的效果实际上与struts-default.xml的效果是相同的。这样，通过各种各样不同的plugin，就等于将Struts2的配置，按照plugin的功能不同而分开了。从而起到了配置文件模块化管理的效果。

使用include节点

plugin中的配置文件，实际上是位于classpath的JAR包中的，那么我们在项目中，如何对一个庞大的配置文件进行拆分呢？在Struts2中，可以使用include节点对所有的Struts2配置文件进行拆分和模块化管理。例如：
Xml代码
  1. <struts>  
  2.   
  3.     <include file="struts-default.xml"/>  
  4.     <include file="web/struts-config.xml"/>  
  5.     <include file="web/struts-action.xml"/>  
  6.        
  7. </struts>  

其中，file所指定的文件是相对于classpath的相对目录中的文件。而每个配置文件的格式与struts-default.xml的格式也是相同的。

通过include节点，我们就可以对一个比较大的配置文件按照功能和模块进行拆分，这在一个大型的团队开发中，是相当有意义的。

简单的IoC

在基本配置定义中，有两个很常用的节点：<bean>和<constant>。在系统启动的时候，Struts2会根据配置文件中这些<bean>和<constant>节点的定义进行加载，并初始化成为Struts2的默认行为。这种初始化的行为，非常类似于Spring中的依赖注入（IoC），从而使得你不再需要担心这些对象在运行时的创建和销毁，所有的工作都由Struts2内部的机制实现。接下来我们就来看看Struts2是如何实现IoC的。

Struts2 Reference 写道
Internally, the framework uses its own dependency injection container that is very similar to Google Guice (both were originally developed by Bob Lee)


这是来自于Struts2的Reference对它自身的IoC的描述。如果熟悉Guice的朋友一定知道，Guice的实现使用了Annotation的方式进行，而整个依赖注入的实现，是通过一个内部的容器类进行的。Struts2的依赖注入，与Guice的机制完全一致。根据注入的内容的不同，Struts2的IoC可以对容器中的对象的依赖关系进行管理，也可以注入一些静态变量。

bean注入

对于bean的注入，对应于XML中的bean的节点声明。我把其中的机制分成了3个部分：

1. 容器中对象的声明

Xml代码
  1. <bean class="com.opensymphony.xwork2.ObjectFactory" name="xwork" />  
  2. <bean type="com.opensymphony.xwork2.ObjectFactory" name="struts" class="org.apache.struts2.impl.StrutsObjectFactory" />  


这点没什么好说的，在struts.xml中，你可以为某个接口声明它所对应的实现类。

name属性

你可以声明多个实现类，使用name属性进行区分。在注入的时候，将使用这个属性的值作为接口实现类的选择。

required属性

你还可以通过required属性，来指定是否在运行时必不可少的注入。如果reqired被设置成false，那么当不存在相应的接口定义时，注入将被忽略。

static属性

在XML的定义中，还可以使用static属性。如果static属性被设置成true，那么注入将针对bean中的static方法和static属性进行。

2. 在代码中使用Annotation进行注入

Java代码
  1. @Inject("xwork")   
  2. protected ObjectFactory objectFactory;   
  3.   
  4. public LightURLUnknownHandler(@Inject ObjectFactory objectFactory) {   
  5.     this.objectFactory = objectFactory;   
  6. }   
  7.   
  8. @Inject  
  9. public void setObjectFactory(ObjectFactory factory) {   
  10.     this.objectFactory = factory;   
  11. }   
  12.   
  13. @Inject(required=false)   
  14. public void setUnknownHandler(UnknownHandler handler) {   
  15.     this.unknownHandler = handler;   
  16. }  


在代码中，使用@Inject这样一个Annotation进行对象依赖注入。在上面的例子中，我们可以看到，@Inject这个Annotation，可以作用在属性上，也可以作用在方法上，甚至可以作用在方法的参数上。

在默认情况下，如果@Inject不指定value，那么XML配置定义中的name="default"或者name=""的实现类定义将被注入。

那么，在struts-default.xml中，Struts2到底选择了那些实现类，作为Struts2或者XWork内部接口的默认实现类呢？默认情况下，struts-default.xml中定义的bean的name="struts"的将被作为默认的接口实现类被注入。这些默认行为，是由org.apache.struts2.config.BeanSelectionProvider所决定的，有兴趣的读者可以参阅这个类的源码。

3. 内部的Container机制完成一切背后工作

上面看到的，是现象。在内部，Struts2通过一个Container来实现所有的注入机制。

Java代码
  1. public interface Container extends Serializable {   
  2.   
  3.   /**  
  4.    * Default dependency name.  
  5.    */  
  6.   String DEFAULT_NAME = "default";   
  7.   
  8.   /**  
  9.    * Injects dependencies into the fields and methods of an existing object.  
  10.    */  
  11.   void inject(Object o);   
  12.   
  13.   /**  
  14.    * Creates and injects a new instance of type {@code implementation}.  
  15.    */  
  16.   <T> T inject(Class<T> implementation);   
  17.   
  18.   /**  
  19.    * Gets an instance of the given dependency which was declared in  
  20.    * {@link com.opensymphony.xwork2.inject.ContainerBuilder}.  
  21.    */  
  22.   <T> T getInstance(Class<T> type, String name);   
  23.   
  24.   /**  
  25.    * Convenience method.&nbsp;Equivalent to {@code getInstance(type,  
  26.    * DEFAULT_NAME)}.  
  27.    */  
  28.   <T> T getInstance(Class<T> type);   
  29.      
  30.   /**  
  31.    * Gets a set of all registered names for the given type  
  32.    * @param type The instance type  
  33.    * @return A set of registered names  
  34.    */  
  35.   Set<String> getInstanceNames(Class<?> type);   
  36.   
  37.   /**  
  38.    * Sets the scope strategy for the current thread.  
  39.    */  
  40.   void setScopeStrategy(Scope.Strategy scopeStrategy);   
  41.   
  42.   /**  
  43.    * Removes the scope strategy for the current thread.  
  44.    */  
  45.   void removeScopeStrategy();   
  46. }  


在系统启动的时候，这个Container的实现类就会工作，把XML中定义的内容进行注入。有兴趣的读者可以继续探寻这个接口的实现类：com.opensymphony.xwork2.inject.ContainerImpl。

静态变量（Constant）的注入

@Inject这个Annotation不仅能够对接口的实现类进行注入，也能够对静态变量进行注入。

有关静态变量的声明和注入，在我的另外一篇专栏文章中已经详细阐述：《深入plugin》 ——  http://www.javaeye.com/wiki/struts2/1333-deep-into-plugin。在这里，我也就不详细介绍了。

package节点详解

package节点是整个配置的核心部分。每个package，从语义上讲，其实代表了每一个独立的模块。在这个模块中，你可以定义隶属于这个模块的行为方式，而与其他的模块没有关系。所以，每个package都有独立的interceptor、result-type和action的定义，绝大多数的Runtime配置定义都是通过package节点实现的。接下来我们就来详细讨论一下package中的属性和子节点。

基本属性

1. name

name属性为每个package设置一个唯一的标识，这个标识在所有的package定义中不能重复。

2. abstract

标识这个package的定义是一个抽象定义，也就是允许他仅包含声明式的定义，而不需要在package定义中包含action的定义。

3. extends

通过使用extends，你可以指定本package继承另外一个package的所有的配置。当某个package继承了另外一个package的所有配置，那么你就无需对父package中已经声明过的配置定义做再次的定义。

同时，如果重复定义父package中已声明过的配置定义，那么这些重复定义声明将覆盖父package中的相关定义。

4. namespace

Struts2 Reference 写道
The namespace attribute subdivides action configurations into logical modules, each with its own identifying prefix. Namespaces avoid conflicts between action names. Each namespace can have its own "menu" or "help" action, each with its own implementation.


这段来自Struts2的Reference的引用，基本上阐明了namespace的作用：对于action配置进行逻辑划分。

如果我们不为package节点指定namespace，Struts2默认使用一个空字符串作为默认的namespace。当然，也可以使用"/"等字符串来表示namespace。

Struts2在根据URL进行寻址的时候，使用以下的步骤：

1) 根据URL进行Namespace和ActionName的计算

2) 根据计算的得到的Namespace和ActionName查找package节点中相应配置

3) 如果查找失败，则查找Namespace为空，ActionName为整个URL的配置

有关上述3点的详细信息，请参考Struts2的Reference：http://struts.apache.org/2.0.14/docs/namespace-configuration.html

result-types节点

在result-types节点中，我们可以声明在本package中所支持的Result类型。这些Result类型，将在action节点中被引用到。

interceptors节点

在interceptors节点中有两类节点：<interceptor>和<interceptor-stack>。这两个节点都用于声明拦截器。前者的作用，是真正定义一个拦截器。而后者则通过引用已经定义的拦截器，指定他们的执行顺序。

当我们在试图在Action中引用拦截器时，我们实际上是为某个Action指定需要执行哪些拦截器，并且为这些拦截器指定执行顺序。所以Action所引用的，是某个<interceptor-stack>中的定义。

缺省配置指向

为了简化配置，我们可以在package节点中指定本package内的缺省配置指向。这可以通过<default-interceptor-ref>、<default-action-ref>、<global-results>等子节点来完成。

action节点

action节点是所有的Runtime配置的核心内容。它的主要作用就是指定URL与Action之间的映射关系。同时，在action节点中你也可以指定action执行时的相关配置，例如action所引用的interceptor等。

参考文档

上面所有的内容，实际上我只是做了一些简单的概括和归纳，至于每个节点语义和每个节点中具体属性的使用，我认为还是需要参考Struts2的Reference，因为Reference的讲解比任何教程都来的详细和正确，所以希望大家在了解了这些配置的基本分类之后，重新阅读Struts2的Reference的相关章节，从而更加深刻的理解Struts2配置文件的方方面面：http://struts.apache.org/2.0.14/docs/configuration-elements.html
posted @ 2009-07-23 14:54  蟋蟀的草坪  阅读(1594)  评论(0)  编辑  收藏  举报