Action 類:
Struts1要求Action類繼承壹個抽象基類。Struts1的壹個普遍問題是使用抽象類編程而不是接口，而struts2的Action是接口。 Struts 2 Action類可以實現壹個Action接口，也可實現其他接口，使可選和定制的服務成為可能。Struts2提供壹個ActionSupport基類去 實現 常用的接口。Action接口不是必須的，任何有execute標識的POJO對象都可以用作Struts2的Action對象。線程模式:
Struts1 Action是單例模式並且必須是線程安全的，因為僅有Action的壹個實例來處理所有的請求。單例策略限制了Struts1 Action能作的事，並且要在開發時特別小心。Action資源必須是線程安全的或同步的。 Struts2 Action對象為每壹個請求產生壹個實例，因此沒有線程安全問題。（實際上，servlet容器給每個請求產生許多可丟棄的對象，並且不會導致性能和垃圾回收問題）Servlet 依賴:
Struts1 Action 依賴於Servlet API ,因為當壹個Action被調用時HttpServletRequest 和 HttpServletResponse 被傳遞給execute方法。 Struts 2 Action不依賴於容器，允許Action脫離容器單獨被測試。如果需要，Struts2 Action仍然可以訪問初始的request和response。但是，其他的元素減少或者消除了直接訪問HttpServetRequest 和 HttpServletResponse的必要性。可測性:
測試Struts1 Action的壹個主要問題是execute方法暴露了servlet API（這使得測試要依賴於容器）。壹個第三方擴展－－Struts TestCase－－提供了壹套Struts1的模擬對象（來進行測試）。 Struts 2 Action可以通過初始化、設置屬性、調用方法來測試，“依賴註入”支持也使測試更容易。捕獲輸入:
Struts1 使用ActionForm對象捕獲輸入。所有的ActionForm必須繼承壹個基類。因為其他JavaBean不能用作ActionForm，開發者經常創建多余的類捕獲輸入。動態Bean（DynaBeans）可以作為創建傳統ActionForm的選擇，但是，開發者可能是在重新描述(創建)已經存 在的JavaBean（仍然會導致有冗余的javabean）。 Struts 2直接使用Action屬性作為輸入屬性，消除了對第二個輸入對象的需求。輸入屬性可能是有自己(子)屬性的rich對象類型。Action屬性能夠通過 web頁面上的taglibs訪問。Struts2也支持ActionForm模式。rich對象類型，包括業務對象，能夠用作輸入/輸出對象。這種 ModelDriven 特性簡化了taglib對POJO輸入對象的引用。表達式語言：
Struts1 整合了JSTL，因此使用JSTL EL。這種EL有基本對象圖遍歷，但是對集合和索引屬性的支持很弱。 Struts2可以使用JSTL，但是也支持壹個更強大和靈活的表達式語言－－"Object Graph Notation Language" (OGNL).綁定值到頁面（view）:
Struts 1使用標準JSP機制把對象綁定到頁面中來訪問。 Struts 2 使用 "ValueStack"技術，使taglib能夠訪問值而不需要把妳的頁面（view）和對象綁定起來。ValueStack策略允許通過壹系列名稱相同但類型不同的屬性重用頁面（view）。類型轉換：
Struts 1 ActionForm 屬性通常都是String類型。Struts1使用Commons-Beanutils進行類型轉換。每個類壹個轉換器，對每壹個實例來說是不可配置的。 Struts2 使用OGNL進行類型轉換。提供基本和常用對象的轉換器。校驗：
Struts 1支持在ActionForm的validate方法中手動校驗，或者通過Commons Validator的擴展來校驗。同壹個類可以有不同的校驗內容，但不能校驗子對象。 Struts2支持通過validate方法和XWork校驗框架來進行校驗。XWork校驗框架使用為屬性類類型定義的校驗和內容校驗，來支持chain校驗子屬性Action執行的控制：
Struts1支持每壹個模塊有單獨的Request Processors（生命周期），但是模塊中的所有Action必須***享相同的生命周期。 Struts2支持通過攔截器堆棧（Interceptor Stacks）為每壹個Action創建不同的生命周期。堆棧能夠根據需要和不同的Action壹起使用。壹、 引言Struts的第壹個版本是在2001年5月份發布的。它的最初設想是通過結合JSP和Servlet，使Web應用的視圖和業務/應用邏輯得以清晰地分離開來。在Struts之前，最常見的做法是在JSP中加入業務和應用邏輯，或者在Servlet中通過println()來生成視圖。
自從第壹版發布以來，Struts實際上已成為業界公認的Web應用標準。它的炙手可熱也為自己帶來了改進和變更，所以不但要跟上對Web應用框架不斷變化的需求，而且要與日漸增多競爭激烈的眾多框架的特性相融合。到最後，產生了幾個下壹代Struts的解決方案。其中兩個最受矚目的方案是Shale和Struts Ti。
Shale是壹個基於構件的框架，並在最近成為Apache的頂級項目。而Struts Ti則是在Struts的成功經驗基礎上繼續堅持對前端控制器（Front Controller）和MVC（model-view-controller）模式進行改進。WebWork項目是在2002年3月發布的，它對Struts式框架進行了革命性改進，引進了不少新的思想、概念和功能，但和原Struts代碼並不兼容。WebWork是壹個成熟的框架，經過了好幾次重大的改進與發布。在2005年12月，WebWork與Struts Ti宣布合並。與此同時，Struts Ti改名為Struts Action Framework 2.0，成為Struts真正的繼承者。最後要註意的是，並不是說Struts或WebWork項目已經停止開發了。由於人們對這兩個項目的興趣仍然很高，而且也有很多開發者仍然願意使用它們，因此這兩個項目還在繼續開發中，繼續修復Bug，改進功能和繼續添加新功能。
二、 Action的區別對於有著豐富的Struts1.x開發經驗的朋友來說，都十分的清楚Action是整個Struts框架的核心內容，當然Struts2也不例外。不過，Struts1.x與Struts2的Action模型很大的區別。Struts2和Struts1.x的差別，最明顯的 就是Struts2是壹個pull-MVC架構。
這是什麽意思呢？從開發者角度看，就是說需要顯示給用戶的數據可以直接從Action中獲取，而不像 Struts1.x那樣，必須把相應的Bean存到Page、Request或者Session中才能獲取。Struts1.x 必須繼承org.apache.struts.action.Action或者其子類，表單數據封裝在FormBean中。
Struts 2無須繼承任何類型或實現任何接口，表單數據包含在Action中，通過Getter和Setter獲取（如下面的ActionForStruts2的代碼示例）。雖然，在理論上Struts2的Action無須實現任何接口或者是繼承任何的類，但是，在實際編程過程中，為了更加方便的實現Action，大多數情況下都會繼承com.opensymphony.xwork2.ActionSupport類，並且重載（Override）此類裏的String execute()方法。
首先，從ActionForStruts2可以看出，返回的對象不是ActionForward，而是String。如果妳不喜歡以字符串的形式出現在妳的代碼中，有個Helper接口Action可以以常量方式提供常見結果，如“success”、“none”、“error”、“input”和“login”。
另外，按照慣例，在Struts1.x中只有“execute”方法能調用Action, 但在Struts2中並非必要，任何聲明為public String methodName() 方法，都能通過配置來調用Action。
最後，和Struts1.x最大的革命性的不同是，Struts2處理Action過程中調用的方法（“execute”方法）是不帶參數的。
那如何獲取所需要的對象呢？答案是使用IoC（反轉控制，Inversion of Control)，也叫“依賴註入（Dependency Injection）”的模式。Spring框架使得這個模式流行起來，然而Struts2的前身（WebWork）也同時應用上了這個模式。
三、 IoCIoC(Inversion of Control，以下譯為控制反轉），隨著Java社區中輕量級容器（Lightweight Contianer）的推廣而越來越為大家耳熟能詳。在此，無需再多費唇舌來解釋“什麽是控制反轉”和“為什麽需要控制反轉”。
眾所周知，Struts2是以Webwork 2作為基礎發展出來。而在Webwork 2.2之前的Webwork版本，其自身有壹套控制反轉的實現，Webwork 2.2在Spring 框架的如火如荼發展的背景下，決定放棄控制反轉功能的開發，轉由Spring實現。
值得壹提的是，Spring確實是壹個值得學習的框架，因為有越來越多的開源組件（如iBATIS等）都放棄與Spring重疊的功能的開發。因此，Struts2推薦大家通過Spring實現控制反轉。
為了更好地了解反轉控制，下面來看壹個例子，如何利用IoC在Action處理過程中可以訪問到當前請求HttpServerRequest對象。在例子中，使用的依賴註入機制是接口註入。就如其名稱壹樣，接口註入需要的是已經被實現了的接口。
這個接口包含了相應屬性的setter，為Action提供值。
例子中使用了ServletRequestAware接口，如下：
public interface ServletRequestAware { public void setServletRequest(HttpServletRequest request);}
當繼承這個接口後，原本簡單的Action看起來有點復雜了，但是這時可以獲取HttpServerRequest對象來使用了。
public class IoCForStruts2 implements ServletRequestAware {
private HttpServletRequest request;
public void setServletRequest(HttpServletRequest request) {
this.request = request; }
public String execute() throws Exception {
// 可以開始使用request對象進行工作了
return Action.SUCCESS; }
}
看起來現在這些屬性是類級別的，並不是線程安全的，會出現問題。
其實在Struts2裏並沒有問題，因為每個請求過來的時候都會產生壹個新的Action對象實例，它並沒有和其他請求***享壹個對象，所以不需要考慮線程安全問題。
攔截器 Interceptor（以下譯為攔截器），在AOP（Aspect-Oriented Programming）中用於在某個方法或字段被訪問之前，進行攔截然後在之前或之後加入某些操作。
攔截是AOP的壹種實現策略。在Webwork的中文文檔的解釋為——攔截器是動態攔截Action調用的對象。它提供了壹種機制可以使開發者定義在壹個action執行的前後執行的代碼，也可以在壹個action執行前阻止其執行。同時也提供了壹種可以提取action中可重用的部分的方式。Struts1.x的標準框架中不提供任何形式的攔截器，雖壹個名為SAIF的附加項目則實現了這樣的功能，但它的適用的範圍還很有限。
攔截器是Struts2的壹個強有力的工具，有許多功能（feature）都是構建於它之上，如國際化、轉換器，校驗等。談到攔截器，還有壹個流行的詞——攔截器鏈（Interceptor Chain，在Struts2中稱為攔截器棧Interceptor Stack）。
攔截器鏈就是將攔截器按壹定的順序聯結成壹條鏈。在訪問被攔截的方法或字段時，攔截器鏈中的攔截器就會按其之前定義的順序被調用。
Struts 2的攔截器實現相對比較簡單。當請求到達Struts2的ServletDispatcher時，Struts 2會查找配置文件，並根據其配置實例化相對的攔截器對象，然後串成壹個列表（list），最後壹壹地調用列表中的攔截器，Struts 2已經提供豐富多樣功能齊全的攔截器實現。
讀者可以到struts2-all-2.0.6.jar或struts2-core-2.0.6.jar包的struts-default.xml查看關於默認的攔截器與攔截器鏈的配置。作為“框架（framework）”，可擴展性是不可缺少的，因為世上沒有放之四海而皆準的東西。
雖然，Struts 2為我們提供如此豐富的攔截器實現，但是這並不意味我們失去創建自定義攔截器的能力，恰恰相反，在Struts 2自定義攔截器是相當容易的壹件事。
前面已經簡要介紹了 Struts2的起源，並詳細對比了Struts2和Struts1.x的差異，讀者應該對Struts2的基礎有所了解了——包括高層的框架概念和基礎 的請求流程，並理解Struts1.x和Struts2兩者之間在Action方面的差別，Struts2加強了對攔截器與IoC的支持，而在 Struts1.x中，這些特性是很難想象的。
同時，應該明白： Struts2是WebWork的升級，而不是Struts 1.x的升級。雖然Struts 2提供了與Struts1.x的兼容，但已經不是Struts1.x的升級。對於已有Struts1.x開發經驗的開發者而言，Struts1.x的開發 經驗對於Struts2並沒有太大的幫助；相反，對於已經有WebWork開發經驗的開發者而言，WebWork的開發經驗對Struts2的開發將有很 好的借鑒意義。