處理流程

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 容器交互。