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

AroundInterceptor攔截機-->
DefaultActionInvocation中有一個數(shù)組維護(hù)了攔截機的執(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>配置有何關(guān)聯(lián)?

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

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

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