對請求進行處理的元素主要有interceptors、Action以及Result。下面分別對其進行講述。
1．攔截器配置(interceptors)
通過使用攔截器，我們可以在action中的方法執行之前先執行一些我們事先定義好了的方法，也可以在action中的方法執行之後立即執行一些我們事先定義好了的方法。在開發的過程中，攔截器將是一個強有力的工具。攔截器有很多很多的功能，如校驗、屬性封裝、安全、日誌等等，如下表所示：
表1：攔截器功能表
|
校驗(validation) |
檢查輸入是否正確 |
|
屬性封裝(property population) |
將輸入傳輸和轉化爲對象的屬性 |
|
日誌(logging) |
記錄關於每個action的詳細信息 |
|
切面(profiling) |
記錄action的吞吐量，尋找性能瓶頸(不是很懂) |
我們可以將多個攔截器鏈接在一起形成一個攔截器棧。比方說一個action不僅要對客戶端的資格進行審查，還要記錄它自己的行爲，那麼我們可以將實現這兩個功能的攔截器放在一起，形成一個攔截器棧(interceptor stack)。攔截器是以java類的形式實現的，因此每一個攔截器都有一個唯一的類名。爲了讓對攔截器的參考更加容易，我們可以在框架中爲每個攔截器註冊一個更簡單的名字。下面給出了一個註冊攔截器的例子：
在定義一個攔截器棧的時候，單個的攔截器和攔截器棧可以以任意的順序混合在一起，struts框架將會按照攔截器在棧裏面的順序調用它們。大多說應用程序都會定義一個默認的攔截器棧，如：<default-interceptor-ref name="defaultStack"/>，默認的攔截器棧會作用於package中的每個action上。當然action還可以定義它自己的本地(局部)棧，如下面例子所示：
2．Action配置
action mappings是框架中的基本工作單元，框架通過對請求的request路徑進行映射來決定由哪個action來處理請求。action mappings能指定一系列的result、異常處理器以及攔截器。action元素的所有屬性中只有name屬性是必須的，其它屬性都是可選的。關於如何從請求路徑映射到action在namespace那節中已經說過了，這裏就不說了。儘管對於action的命名很靈活，但是action的名字中最好不要出現斜線(/)、點號(.)、破折號(/)，以免出現一些不可預知的錯誤。
在Action接口中定義了action默認的方法入口，它就是execute方法。但是並不是每個action類都必須實現這個接口，如果action類沒有實現這個接口的話，框架將使用反射來尋找一個execute方法。有時候我們的action中可能會包括多個方法入口，並且不同的情況下方法入口不同，例如執行修改操作時我們想進入action的mofify方法，執行增加操作時進入action的add方法，這個時候怎麼辦呢？我們可以通過指定action元素的method屬性來實現，如下所示：
如果在action類中沒有execute方法，也沒有在配置文件中指定其它的方法，框架會拋出異常。
很多時候，多個action mapping會共享一個相同的模式，這個時候我們可以使用通配符方法。還是舉例來說,如下所示。
<action name=”editCrud” class=”example.CrudAction” method=”edit”/>
<action name=”deleteCrud” class=” example.CrudAction” method=” delete”/>
上述兩個action mapping調用的是同一個action類，只是執行的方法不同而已，並且所執行的方法名都是action mapping名字的開頭部分，而且action mapping的名字除去方法名之後剩下的部分是一樣的。這種情況下我們可以使用一個action mapping來代替上面兩個action mapping：
<action name=”*Crud” class=”example.CrudAction” method=”{1}”>
匹配過程是這樣的 (以請求的action mapping的名字是editCrud爲例) ：
● *可以表示任何內容，因此任何以Crud結尾的action mapping都會匹配上
● 當editCrud匹配上後，*的內容此時就是edit
● 調用名字爲第一個*號的內容的方法，此時僅有一個*號，並且此時它的內容爲edit，因此action類的edit方法被調用了
● 同理，如果請求的action是deleteCrud，匹配成功後*的內容就是delete，調用的方法就是delete了。
使用通配符匹配方法可以讓我們減少配置文件的內容，是配置更加簡潔。
如果我們沒有給action元素指定class屬性的話，框架會默認它的class屬性爲com.opensymphony.xwork.ActionSupport，如果想指定別的類作爲默認的Action類，可以通過package的default-action-ref屬性來設置。在設置了default-action-ref之後，如果我們在package中沒有匹配到所請求的action，那麼這個默認的action就會被調用。一般一個命名空間下最好只定義一個默認的action。
3．Result元素配置
action類處理完一個請求後會返回一個字符串，這個字符串將被用來選擇一個result元素。通常一個action mapping會有多個result，代表各個可能不同的結果。ActionSupport中定義了幾個標準的result token，如下所示：
通常我們都會自定義一些result token類匹配特定的情況。
result元素負責完成兩個工作：1.提供一個邏輯名用於與action類的返回字符串進行匹配；2.提供一個返回類型(Result Type)。儘管大多數的result只是簡單的轉向一個頁面或模板，但是我們還可以利用其它的返回類型(Result Type)做其它的一些事情。我們可以爲每個包設置默認的返回類型(Result Type)，如果一個包繼承了另外一個包，它可以選擇設置自己的默認返回類型或者直接使用父包的。設置默認返回類型的方式如下：
Result元素有兩個屬性：name和type，它們都是可選的，name屬性的默認值是“success”，type的屬性爲我們所設置的默認返回類型，如上例中即爲dispatcher。
定義在action元素裏面的result我們可以稱之爲局部result，除此之外我們可以還可以全局的result，這些result會被多個action所共享。框架會首先尋找嵌套在action元素中的result，如果沒有匹配的就去全局result中去尋找。一個全局result的例子如下：
有時候我們的result在運行前可能是未知的。比方說，一個result它所跳轉的頁面取決於它所在action類的運行結果或者客戶端的輸入等等，這時候我們可以使用動態的result，也就是說result的值可以使用表達式語言(EL)來表示，這個表達式的值是動態的，取決於action的運行時狀況，下面是一個例子：
在上例中result的值將是它所在action的nextAction的屬性值，nextAction屬性的值不同，當action的方法返回”next”時所跳向的url也不同。
