struts2攔截器interceptor

在之前的文章中，我們已經涉及到了攔截器（Interceptor）的概念。

downpour 寫道

攔截器是AOP中的概念，它本身是一段代碼，可以通過定義“織入點”，來指定攔截器的代碼在“織入點”的前後執行，從而起到攔截的作用。正如上面 Struts2的Reference中講述的，Struts2的Interceptor，其攔截的對象是Action代碼，可以定義在Action代碼之前或者之後執行攔截器的代碼。

接下來，我們將重點討論一下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;
}

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;
}

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);
}

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>

<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);
}
}

/**
 * @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);

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;
}

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又會按照剛開始執行的逆向順序依次執行結束。

小U仔

發佈了27 篇原創文章 · 獲贊 1 · 訪問量 5萬+

私信關注

struts2攔截器interceptor

目錄 [ - ]

Interceptor結構

Interceptor執行分析

源碼解析

java在zookeeper節點上註冊監聽器

SessionFactory、HibernateTemplate、HibernateDaoSupport之間的關係說明

基於XML配置方式實現對action的所有方法進行輸入校驗

淺談Struts2攔截器的原理與實現

SSH pager-taglib分頁的實現

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

struts2攔截器interceptor

目 錄 [ - ]

Interceptor結構

Interceptor執行分析

源碼解析

目錄 [ - ]