action的默認結果類型是dispatcher，而action之間發送請求是不能直接用該結果類型的。一般來說，可選的結果有redirect、redirect-action、chain。前兩種都是屬於頁面跳轉，也就是說，發送請求以後，地址欄的地址會刷新爲被請求的action的地址，而chain則不會更新地址。
redirect-action：“這個Result使用ActionMapperFactory提供的ActionMapper來重定位瀏覽器的URL來調用指定的action和(可選的)namespace. 這個Result比ServletRedirectResult要好.因爲你不需要把URL編碼成xwork.xml中配置的ActionMapper提供的模式. 這就是說你可以在任意點上改變URL模式而不會影響你的應用程序. 因此強烈推薦使用這個Result而不是標準的redirect result來解決重定位到某個action的情況.”---webwork2的說法。
redirect：“調用{@link HttpServletResponse#sendRedirect(String) sendRedirect}方法來轉到指定的位置。HTTP響應被告知使瀏覽器直接跳轉到指定的位置(產生客戶端的一個新請求). 這樣做的結果會使剛剛執行的action(包括action實例,action中的錯誤消息等)丟失, 不再可用。”
簡單說，兩者的共同點是，地址欄會變化，所有前一個action的請求參數都會丟失，當然也包括action的屬性值也會丟失。路徑寫法稍有不同，redirect-action請求下一個action時，不帶後綴.action，而redirect和普通URL寫法一致。redirect-action支持param來附加請求參數，但是這往往會導致ServletActionRedirectResult報找不到xxx屬性的警告，這大概是由於無法識別是IOC注入，還是參數附加URL導致的，雖然是WARN級別，不過寧可寫成xxx?a=x&b=y的形式，而&還需要寫作&的格式，否則會報xml格式錯誤。（另外，這種url形式，作爲param的actionName的值也是可以正常使用的）
chain：相當於是forward，首先表現爲地址欄不會改變，類似dispatcher，同時，它的特點是能夠在多個action中共享表單傳遞過來的數據，同時，按照action鏈的順序，相關action的屬性值也會傳遞下去，這表示在最後的視圖頁，你可以得到前面所有action的屬性值（如果有get方法的話）。對於多個action具有相同屬性值的話，後續action會先使用前面的action的數據來進行賦值，然後再進行邏輯處理並傳遞下去。
看起來是很完美，可是卻有很大的問題。如果後面的action需要調用前面action的屬性值，他得保證具有同樣的屬性值，否則你無法接收到前面action的值。他無法像redirect-action一樣通過附加參數獲取，他不支持xxx?a=x&b=y的形式。這將導致很大的耦合性和無效參數的泛濫，無法通過配置文件傳遞參數也很麻煩。
另外，很困擾的一點就是，如果在action鏈靠前的action方法內出現錯誤（如action的hasError方法返回true）或者發生異常，他就會強迫你定義input結果，包括後面的action也要定義，否則就會報錯。而實際上，即使符合了以上條件，他仍不會執行後面的action，而是直接跳到後面的action的input視圖。除非發生錯誤的action返回input，並且type爲“chain”，並且後一個action的方法必須爲input，否則後續方法不會執行，而直接定位到了最後的物理視圖。
這讓我覺得chain的適用範圍變的十分窄，據說webwork2已經不提倡使用chain，這個沒考證過。
