处理流程

1、在struts2中所有的请求由org.apache.struts2.dispatcher.FilterDispatcher传递过来。从请求的服务名解析出对应的action名称，并遍历HttpServletRequest、HttpSession、ServletContext 中的数据，并将其复制到Webwork的Map实现中，至此之后，所有数据操作均在此Map结构中进行，从而将内部结构与Servlet API相分离。

2、以上述信息作为参数，调用ActionProxyFactory创建对应的ActionProxy实例。ActionProxyFactory 将根据Xwork 配置文件（xwork.xml）中的设定，创建ActionProxy实例，ActionProxy中包含了Action的配置信息（包括Action名称，对应实现类等等）。

3、ActionProxy创建对应的Action实例，并根据配置进行一系列的处理程序。包括执行相应的预处理程序（如通过Interceptor 将Map 中的请求数据转换为Action所需要的Java 输入数据对象等），以及对Action 运行结果进行后处理。ActionInvocation 是这一过程的调度者。而com.opensymphony.xwork.
DefaultActionInvocation 则是XWork 中对ActionInvocation 接口的标准实现，如
果有精力可以对此类进行仔细研读，掌握了这里面的玄机，相信XWork的引擎就不再神秘。

一段配置文件件及期解析

include
通过include 节点，我们可以将其他配置文件导入到默认配置文件xwork.xml 中。从而实现良好的配置划分。这里我们导入了Webwork 提供的默认配置webwork-default.xml（位于webwork.jar 的根路径）。

package
XWork中，可以通过package对action进行分组。类似Java 中package和class的
关系。为可能出现的同名Action提供了命名空间上的隔离。
同时，package还支持继承关系。在这里的定义中，我们可以看到：
extends="webwork-default""webwork-default"是webwork-default.xml文件中定义的package，这里通过继承，"default" package 自动拥有"webwork-default" package 中的所有定义关系。这个特性为我们的配置带来了极大便利。在实际开发过程中，我们可以根据自身的应用特点，定义相应的package模板，并在各个项目中加以重用，无需再在重复繁琐的配置过程中消耗精力和时间。此外，我们还可以在Package节点中指定namespace，将我们的action分为若干个逻辑区间。如：<package name="default" namespace="/user"extends="webwork-default">就将此package中的action定义划归为/user 区间，之后在页面调用action的时候，我们需要用/user/login.action 作为form action 的属性值。其中的/user/就指定了此action的namespace，通过这样的机制，我们可以将系统内的action进行逻辑分类，从而使得各模块之间的划分更加清晰。
action
Action配置节点，这里可以设定Action的名称和对应实现类。
result
通过result 节点，可以定义Action 返回语义，即根据返回值，决定处理模式以及响应界面。这里，返回值"success"（Action 调用返回值为String 类型）对应的处理模式为"dispatcher"。
可选的处理模式还有：
1. dispatcher
本系统页面间转向。类似forward。
2. redirect
浏览器跳转。可转向其他系统页面。
3. chain
将处理结果转交给另外一个Action处理，以实现Action的链式处理。
4. velocity
将指定的velocity模板作为结果呈现界面。
5. xslt
将指定的XSLT 作为结果呈现界面。
随后的param节点则设定了相匹配的资源名称。
interceptor-ref
设定了施加于此Action的拦截器（interceptor）。关于拦截器，请参见稍后的“XWork拦截器体系”部分。interceptor-ref定义的是一个拦截器的应用，具体的拦截器设定，实际上是继承于webwork-default package，我们可以在webwork-default.xml 中找到对应的"params"和"model-driven"拦截器设置：
关于拦截器可以参考struts-default时的定义总之它就是把请求封装成对象，或把对象封装成。通常我们在<package>节点里包含这段代码，避免重复定义拦截.
然后在不同的Action节里点引用，方法如

Webwork 中的Model对象，扮演着承上启下的角色，它既是Action的输入参数，又包含了Action处理的结果数据。换句话说，输入的Http请求参数，将被存储在Model对象传递给Action进行处理，Action处理完毕之后，也将结果数据放置到Model 对象中，之后，Model 对象与返回界面融合生成最后的反馈页面。也正由于此，笔者建议在实际开发中采用Model-Driven 模式，而非Property-Driven 模式（见稍后“Action驱动模式”部分），这将使得业务逻辑更加清晰可读。

ActionContext为Action提供了与容器交互的途径。对于Web 应用而言，与容器的交互大多集中在Session、Parameter，通过ActionContext我们在代码中实现与Servlet API无关的容器交互。此外， 为了提供与Web 容器直接交互的可能。WebWork 还提供了一个ServletActionContext实现。它扩展了ActionContext，提供了直接面向Servlet API的容器访问机制。

我们可以直接通过ServletActionContext.getRequest 得到当前HttpServletRequest 对象的引用，从而直接与Web 容器交互。