在web.xml文件里配置一個派遣器ServletDispatcher，以接收所有以action結尾的url請求。并進行http請求調(diào)度處理.
<servlet>
   <servlet-name></servlet-name>
   <servlet-class>com.opensymphony.webwork.dispatcher.ServletDispatcher</servlet-class>
</servlet>
<servlet-mapping>
   <servlet-name>webwork</servlet-name>
   <url-pattern>*.action</url-pattern>
</servlet-mapping>
當ServletDispatche調(diào)度器接收到一個.action結尾的請求時，會調(diào)用ServletDispatche類的service方法進行處理,該方法最終是創(chuàng)建一個ActionProxy對象，并通過執(zhí)行ActionProxy中的execute方法來
調(diào)用所請求的Action的execute方法.之前要執(zhí)行一些方法來創(chuàng)造條件：創(chuàng)建Action上下文===>從request中獲得值堆棧stack===>創(chuàng)建ActionProxyFactory對象，并初始化一個DefaultActionProxy對象====>通過DefaultAction的構造函數(shù)調(diào)用ConfigurationManager獲得當前請求的Action在xwork.xml中的配置信息====>DefaultActionProxy中的prepare方法通過創(chuàng)建一個ActionInvocation對象來實現(xiàn)對請求action的調(diào)用。

AroundInterceptor攔截機-->
DefaultActionInvocation中有一個數(shù)組維護了攔截機的執(zhí)行順序：
1、StaticParametersInterceptor, 2、ParametersInterceptor, 3、WebWorkConversionErrorInterceptor
4、ModelDrivenInterceptor 5、ExternalReferencesInterceptor
6、StaticParametersInterceptor 7、parametersInterceptor, 8、WebWorkConversionErrorInterceptor
9、ModelDrivenInterceptor 10、ValidationInterceptor
注：這里1、2、3、4攔截機執(zhí)行了兩次，為什么會執(zhí)行兩次呢?
疑問：這里的執(zhí)行順序和webwork-default.xml中的<interceptors>配置有何關聯(lián)?

Action ---> 根據(jù)Action實現(xiàn)相應的Action,ModelDriven接口調(diào)用基類的
ParametersInterceptor中：
      final Map parameters = ActionContext.getContext().getParameters();

從AroundInterceptor的context中取出頁面提交字段的名稱和值,然后它會先把stack.pus(modelDriven.getModel()); modelDriven.getModel()放到CompoundRoot中(CompounRoot是一個ArrayList)上面提到有四個攔截機執(zhí)行兩次，因為第一次要push進去一個空的對象，方便填值，第二次放的是填充好的對象。也就是Action中getModel()的對象。把值從parameters 設置到OgnlValueStack的CompoundRoot的第一個下標中的Action里的getModel()對象里code:stack.setValue(name, value);name對應的是getModel()對應的字段，value為要填充的值.

     摘要:    最近偶參與一個J2EE項目，應用架框是struts+spring! 持久層用hibernate,由于業(yè)務需要，業(yè)務數(shù)據(jù)來源來二個不同的數(shù)據(jù)庫數(shù)據(jù)庫是Orcale,版本是9.0.1.0.0。由于采用容器管理事務(CMT),對于Spring,一般普通業(yè)務應用我用聲明式事務，因為這樣讓代碼清潔一點，只有對于特殊的業(yè)務我才用編程式事務，如大批量更新時調(diào)用存儲過程。對于WebLog...  閱讀全文          POJO(plain old java Object)[譯：簡單初始Java對象]。它簡單(因為只有set/get方法)嗎？或是我們把應該把它弄得復雜點(帶點業(yè)務判斷)？究竟它在我們J2EE應用中扮演一個什么樣的角色呢？一個Anemic Domain Model，Rich Domain Model, DTO, O/R mapping Entity........！以前我的系統(tǒng)中POJO都是一個貧血的模型，只有set/get方法！它的職責就是把前端頁面的數(shù)據(jù)從formBean中轉移過來(用反射)，作為持久層的對象。這里POJO有兩個角色，一個角色是傳送數(shù)據(jù)，另一個是角色是PO(持久對象)。一段時間后我發(fā)現(xiàn)這樣做效率低下，想像一下有些業(yè)務處理，如一個銀行帳戶的pojo,里面有一個金額和利息字段，這個金額是通過一些公式計算后得出來的，開始時我們在業(yè)務層里把金額算出來后set到帳戶pojo金額字段里。我開始思索把一些都是計算或者純邏輯的東西pull Up到pojo中。這時候我的pojo變成一個Domain Object。盡管不是一個Rich的Domain Model,但畢竟前進了一小步。再后來用到了webwork2,由于webwork2里沒有了struts formBean，使用攔截機設值，ModelDriven模式下我的持久Entity就是一個formBean和po的結合,　在ACTIO中它是一個有值的VO，在DAO實現(xiàn)層變成一個PO。在這里我的pojo繼承了O/R Entity類，并把合適的業(yè)務層的代碼都移到相應的了Pojo中，當然沒有持久層的代碼。這樣我的系統(tǒng)的部分pojo變成了Rich Domain Model。在Ejb下，由會話門面管理對POJO業(yè)務對象訪問對比起笨重的entity bean有更高的效率和可移植性。盡管Ejb下的POJO不能享受entity bean的CMP策略，但有了spring 的IOC后，一切變得可配置了！POJO還有很重要的一個優(yōu)勢就是pojo中的業(yè)務可以脫離具體容器運行測試！在這里,pojo是貧血還是沖血應該取決于你的業(yè)務應用，記住：不要把簡單的問題搞復雜了，但把復雜的問題分解成簡單的問題一直就是我們追求的！