接下來,我們將重點討論一下Struts2中的攔截器的內部結構和執行順序,并結合源碼進行分析。
Interceptor結構
讓我們再來回顧一下之前我們曾經用過的一張Action LifeCycle的圖:
圖中,我們可以發現,Struts2的Interceptor一層一層,把Action包裹在最里面。這樣的結構,大概有以下一些特點:
1. 整個結構就如同一個堆棧,除了Action以外,堆棧中的其他元素是Interceptor 2. Action位于堆棧的底部。由于堆棧"先進后出"的特性,如果我們試圖把Action拿出來執行,我們必須首先把位于Action上端的Interceptor拿出來執行。這樣,整個執行就形成了一個遞歸調用 3. 每個位于堆棧中的Interceptor,除了需要完成它自身的邏輯,還需要完成一個特殊的執行職責。這個執行職責有3種選擇:
1) 中止整個執行,直接返回一個字符串作為resultCode
2) 通過遞歸調用負責調用堆棧中下一個Interceptor的執行
3) 如果在堆棧內已經不存在任何的Interceptor,調用Action
Struts2的攔截器結構的設計,實際上是一個典型的
責任鏈模式的應用。首先將整個執行劃分成若干相同類型的元素,每個元素具備不同的邏輯責任,并將他們納入到一個鏈式的數據結構中(我們可以把堆棧結構也看作是一個遞歸的鏈式結構),而每個元素又有責任負責鏈式結構中下一個元素的執行調用。
這樣的設計,從代碼重構的角度來看,實際上是將一個復雜的系統,分而治之,從而使得每個部分的邏輯能夠高度重用并具備高度可擴展性。所以,Interceptor結構實在是Struts2/Xwork設計中的精華之筆。
Interceptor執行分析
Interceptor的定義 我們來看一下Interceptor的接口的定義:
Java代碼

- public interface Interceptor extends Serializable {
-
- /**
- * Called to let an interceptor clean up any resources it has allocated.
- */
- void destroy();
-
- /**
- * Called after an interceptor is created, but before any requests are processed using
- * {@link #intercept(com.opensymphony.xwork2.ActionInvocation) intercept} , giving
- * the Interceptor a chance to initialize any needed resources.
- */
- void init();
-
- /**
- * Allows the Interceptor to do some processing on the request before and/or after the rest of the processing of the
- * request by the {@link ActionInvocation} or to short-circuit the processing and just return a String return code.
- *
- * @return the return code, either returned from {@link ActionInvocation#invoke()}, or from the interceptor itself.
- * @throws Exception any system-level error, as defined in {@link com.opensymphony.xwork2.Action#execute()}.
- */
- String intercept(ActionInvocation invocation) throws Exception;
- }
Interceptor的接口定義沒有什么特別的地方,除了init和destory方法以外,intercept方法是實現整個攔截器機制的核心方法。而它所依賴的參數ActionInvocation則是我們之前章節中曾經提到過的著名的
Action調度者。
我們再來看看一個典型的Interceptor的抽象實現類:
Java代碼

- public abstract class AroundInterceptor extends AbstractInterceptor {
-
- /* (non-Javadoc)
- * @see com.opensymphony.xwork2.interceptor.AbstractInterceptor#intercept(com.opensymphony.xwork2.ActionInvocation)
- */
- @Override
- public String intercept(ActionInvocation invocation) throws Exception {
- String result = null;
-
- before(invocation);
- // 調用下一個攔截器,如果攔截器不存在,則執行Action
- result = invocation.invoke();
- after(invocation, result);
-
- return result;
- }
-
- public abstract void before(ActionInvocation invocation) throws Exception;
-
- public abstract void after(ActionInvocation invocation, String resultCode) throws Exception;
-
- }
在這個實現類中,實際上已經實現了最簡單的攔截器的雛形。或許大家對這樣的代碼還比較陌生,這沒有關系。我在這里需要指出的是一個很重要的方法 invocation.invoke()。這是ActionInvocation中的方法,而ActionInvocation是Action調度者,所 以這個方法具備以下2層含義:
1. 如果攔截器堆棧中還有其他的Interceptor,那么invocation.invoke()將調用堆棧中下一個Interceptor的執行。 2. 如果攔截器堆棧中只有Action了,那么invocation.invoke()將調用Action執行。 所以,我們可以發現,invocation.invoke()這個方法其實是整個攔截器框架的實現核心。基于這樣的實現機制,我們還可以得到下面2個非常重要的推論:
1. 如果在攔截器中,我們不使用invocation.invoke()來完成堆棧中下一個元素的調用,而是直接返回一個字符串作為執行結果,那么整個執行將被中止。 2. 我們可以以invocation.invoke()為界,將攔截器中的代碼分成2個部分,在invocation.invoke()之前的代碼,將會在 Action之前被依次執行,而在invocation.invoke()之后的代碼,將會在Action之后被逆序執行。 由此,我們就可以通過invocation.invoke()作為Action代碼真正的攔截點,從而實現AOP。
Interceptor攔截類型 從上面的分析,我們知道,整個攔截器的核心部分是invocation.invoke()這個函數的調用位置。事實上,我們也正式根據這句代碼的調用位置,來進行攔截類型的區分的。在Struts2中,Interceptor的攔截類型,分成以下三類:
1. before before攔截,是指在攔截器中定義的代碼,它們存在于invocation.invoke()代碼執行之前。這些代碼,將依照攔截器定義的順序,
順序執行。
2. after after攔截,是指在攔截器中定義的代碼,它們存在于invocation.invoke()代碼執行之后。這些代碼,將一招攔截器定義的順序,
逆序執行。
3. PreResultListener
有的時候,before攔截和after攔截對我們來說是不夠的,因為我們需要在Action執行完之后,但是還沒有回到視圖層之前,做一些事 情。Struts2同樣支持這樣的攔截,這種攔截方式,是通過在攔截器中注冊一個PreResultListener的接口來實現的。
Java代碼

- public interface PreResultListener {
-
- /**
- * This callback method will be called after the Action execution and before the Result execution.
- *
- * @param invocation
- * @param resultCode
- */
- void beforeResult(ActionInvocation invocation, String resultCode);
- }
在這里,我們看到,Struts2能夠支持如此多的攔截類型,與其本身的數據結構和整體設計有很大的關系。正如我在之前的文章中所提到的:
downpour 寫道
因為Action是一個普通的Java類,而不是一個Servlet類,完全脫離于Web容器,所以我們就能夠更加方便地對Control層進行合理的層次設計,從而抽象出許多公共的邏輯,并將這些邏輯脫離出Action對象本身。
我們可以看到,Struts2對于整個執行的劃分,從Interceptor到Action一直到Result,每一層都職責明確。不僅如此,Struts2還為每一個層次之前都設立了恰如其分的插入點。使得整個Action層的擴展性得到了史無前例的提升。
Interceptor執行順序 Interceptor的執行順序或許是我們在整個過程中最最關心的部分。根據上面所提到的概念,我們實際上已經能夠大致明白了Interceptor的執行機理。我們來看看Struts2的Reference對Interceptor執行順序的一個形象的例子。
如果我們有一個interceptor-stack的定義如下:
Xml代碼

- <interceptor-stack name="xaStack">
- <interceptor-ref name="thisWillRunFirstInterceptor"/>
- <interceptor-ref name="thisWillRunNextInterceptor"/>
- <interceptor-ref name="followedByThisInterceptor"/>
- <interceptor-ref name="thisWillRunLastInterceptor"/>
- </interceptor-stack>
那么,整個執行的順序大概像這樣:
在這里,我稍微改了一下Struts2的Reference中的執行順序示例,使得整個執行順序更加能夠被理解。我們可以看到,遞歸調用保證了各種各樣的攔截類型的執行能夠井井有條。
請注意在這里,每個攔截器中的代碼的執行順序,在Action之前,攔截器的執行順序與堆棧中定義的一致;而在Action和Result之后,攔截器的執行順序與堆棧中定義的順序相反。
源碼解析
接下來我們就來看看源碼,看看Struts2是如何保證攔截器、Action與Result三者之間的執行順序的。
之前我曾經提到,ActionInvocation是Struts2中的調度器,所以事實上,這些代碼的調度執行,是在 ActionInvocation的實現類中完成的,這里,我抽取了DefaultActionInvocation中的invoke()方法,它將向我 們展示一切。
Java代碼

- /**
- * @throws ConfigurationException If no result can be found with the returned code
- */
- public String invoke() throws Exception {
- String profileKey = "invoke: ";
- try {
- UtilTimerStack.push(profileKey);
-
- if (executed) {
- throw new IllegalStateException("Action has already executed");
- }
- // 依次調用攔截器堆棧中的攔截器代碼執行
- if (interceptors.hasNext()) {
- final InterceptorMapping interceptor = (InterceptorMapping) interceptors.next();
- UtilTimerStack.profile("interceptor: "+interceptor.getName(),
- new UtilTimerStack.ProfilingBlock<String>() {
- public String doProfiling() throws Exception {
- // 將ActionInvocation作為參數,調用interceptor中的intercept方法執行
- resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);
- return null;
- }
- });
- } else {
- resultCode = invokeActionOnly();
- }
-
- // this is needed because the result will be executed, then control will return to the Interceptor, which will
- // return above and flow through again
- if (!executed) {
- // 執行PreResultListener
- if (preResultListeners != null) {
- for (Iterator iterator = preResultListeners.iterator();
- iterator.hasNext();) {
- PreResultListener listener = (PreResultListener) iterator.next();
-
- String _profileKey="preResultListener: ";
- try {
- UtilTimerStack.push(_profileKey);
- listener.beforeResult(this, resultCode);
- }
- finally {
- UtilTimerStack.pop(_profileKey);
- }
- }
- }
-
- // now execute the result, if we're supposed to
- // action與interceptor執行完畢,執行Result
- if (proxy.getExecuteResult()) {
- executeResult();
- }
-
- executed = true;
- }
-
- return resultCode;
- }
- finally {
- UtilTimerStack.pop(profileKey);
- }
- }
從源碼中,我們可以看到,我們之前提到的Struts2的Action層的4個不同的層次,在這個方法中都有體現,他們分別是:攔截器 (Interceptor)、Action、PreResultListener和Result。在這個方法中,保證了這些層次的有序調用和執行。由此我 們也可以看出
Struts2在Action層次設計上的眾多考慮,每個層次都具備了高度的擴展性和插入點,使得程序員可以在任何喜歡的層次加入自己的實現機制改變Action的行為。 在這里,需要特別強調的,是其中攔截器部分的執行調用:
Java代碼

- resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);
表面上,它只是執行了攔截器中的intercept方法,如果我們結合攔截器來看,就能看出點端倪來:
Java代碼

- public String intercept(ActionInvocation invocation) throws Exception {
- String result = null;
-
- before(invocation);
- // 調用invocation的invoke()方法,在這里形成了遞歸調用
- result = invocation.invoke();
- after(invocation, result);
-
- return result;
- }
原來在intercept()方法又對ActionInvocation的invoke()方法進行遞歸調用,ActionInvocation 循環嵌套在intercept()中,一直到語句result = invocation.invoke()執行結束。這樣,Interceptor又會按照剛開始執行的逆向順序依次執行結束。
posted on 2012-12-14 10:41
hellxoul 閱讀(267)
評論(0) 編輯 收藏 所屬分類:
Struts2