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代碼  

1. public interface Interceptor extends Serializable {  
2.   
3.     /** 
4.      * Called to let an interceptor clean up any resources it has allocated. 
5.      */  
6.     void destroy();  
7.   
8.     /** 
9.      * Called after an interceptor is created, but before any requests are processed using 
10.      * {@link #intercept(com.opensymphony.xwork2.ActionInvocation) intercept} , giving 
11.      * the Interceptor a chance to initialize any needed resources. 
12.      */  
13.     void init();  
14.   
15.     /** 
16.      * Allows the Interceptor to do some processing on the request before and/or after the rest of the processing of the 
17.      * request by the {@link ActionInvocation} or to short-circuit the processing and just return a String return code. 
18.      * 
19.      * @return the return code, either returned from {@link ActionInvocation#invoke()}, or from the interceptor itself. 
20.      * @throws Exception any system-level error, as defined in {@link com.opensymphony.xwork2.Action#execute()}. 
21.      */  
22.     String intercept(ActionInvocation invocation) throws Exception;  
23. }  

Interceptor的接口定義沒有什么特別的地方，除了init和destory方法以外，intercept方法是實現整個攔截器機制的核心方法。而它所依賴的參數ActionInvocation則是我們之前章節中曾經提到過的著名的Action調度者。

我們再來看看一個典型的Interceptor的抽象實現類：

Java代碼  

1. public abstract class AroundInterceptor extends AbstractInterceptor {  
2.       
3.     /* (non-Javadoc) 
4.      * @see com.opensymphony.xwork2.interceptor.AbstractInterceptor#intercept(com.opensymphony.xwork2.ActionInvocation) 
5.      */  
6.     @Override  
7.     public String intercept(ActionInvocation invocation) throws Exception {  
8.         String result = null;  
9.   
10.         before(invocation);  
11.         // 調用下一個攔截器，如果攔截器不存在，則執行Action  
12.         result = invocation.invoke();  
13.         after(invocation, result);  
14.   
15.         return result;  
16.     }  
17.       
18.     public abstract void before(ActionInvocation invocation) throws Exception;  
19.   
20.     public abstract void after(ActionInvocation invocation, String resultCode) throws Exception;  
21.   
22. }  

在這個實現類中，實際上已經實現了最簡單的攔截器的雛形。或許大家對這樣的代碼還比較陌生，這沒有關系。我在這里需要指出的是一個很重要的方法 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代碼  

1. public interface PreResultListener {  
2.   
3.     /** 
4.      * This callback method will be called after the Action execution and before the Result execution. 
5.      * 
6.      * @param invocation 
7.      * @param resultCode 
8.      */  
9.     void beforeResult(ActionInvocation invocation, String resultCode);  
10. }  

在這里，我們看到，Struts2能夠支持如此多的攔截類型，與其本身的數據結構和整體設計有很大的關系。正如我在之前的文章中所提到的：

downpour 寫道

因為Action是一個普通的Java類，而不是一個Servlet類，完全脫離于Web容器，所以我們就能夠更加方便地對Control層進行合理的層次設計，從而抽象出許多公共的邏輯，并將這些邏輯脫離出Action對象本身。

我們可以看到，Struts2對于整個執行的劃分，從Interceptor到Action一直到Result，每一層都職責明確。不僅如此，Struts2還為每一個層次之前都設立了恰如其分的插入點。使得整個Action層的擴展性得到了史無前例的提升。

Interceptor執行順序

Interceptor的執行順序或許是我們在整個過程中最最關心的部分。根據上面所提到的概念，我們實際上已經能夠大致明白了Interceptor的執行機理。我們來看看Struts2的Reference對Interceptor執行順序的一個形象的例子。

如果我們有一個interceptor-stack的定義如下：

Xml代碼  

1. <interceptor-stack name="xaStack">  
2.   <interceptor-ref name="thisWillRunFirstInterceptor"/>  
3.   <interceptor-ref name="thisWillRunNextInterceptor"/>  
4.   <interceptor-ref name="followedByThisInterceptor"/>  
5.   <interceptor-ref name="thisWillRunLastInterceptor"/>  
6. </interceptor-stack>  

那么，整個執行的順序大概像這樣：



在這里，我稍微改了一下Struts2的Reference中的執行順序示例，使得整個執行順序更加能夠被理解。我們可以看到，遞歸調用保證了各種各樣的攔截類型的執行能夠井井有條。

請注意在這里，每個攔截器中的代碼的執行順序，在Action之前，攔截器的執行順序與堆棧中定義的一致；而在Action和Result之后，攔截器的執行順序與堆棧中定義的順序相反。

源碼解析

Java代碼  

1. /** 
2.  * @throws ConfigurationException If no result can be found with the returned code 
3.  */  
4. public String invoke() throws Exception {  
5.     String profileKey = "invoke: ";  
6.     try {  
7.         UtilTimerStack.push(profileKey);  
8.               
9.         if (executed) {  
10.             throw new IllegalStateException("Action has already executed");  
11.         }  
12.         // 依次調用攔截器堆棧中的攔截器代碼執行  
13.         if (interceptors.hasNext()) {  
14.             final InterceptorMapping interceptor = (InterceptorMapping) interceptors.next();  
15.             UtilTimerStack.profile("interceptor: "+interceptor.getName(),   
16.                     new UtilTimerStack.ProfilingBlock<String>() {  
17.                         public String doProfiling() throws Exception {  
18.                          // 將ActionInvocation作為參數，調用interceptor中的intercept方法執行  
19.                             resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);  
20.                             return null;  
21.                         }  
22.             });  
23.         } else {  
24.             resultCode = invokeActionOnly();  
25.         }  
26.   
27.         // this is needed because the result will be executed, then control will return to the Interceptor, which will  
28.         // return above and flow through again  
29.         if (!executed) {  
30.             // 執行PreResultListener  
31.             if (preResultListeners != null) {  
32.                 for (Iterator iterator = preResultListeners.iterator();  
33.                     iterator.hasNext();) {  
34.                     PreResultListener listener = (PreResultListener) iterator.next();  
35.                           
36.                     String _profileKey="preResultListener: ";  
37.                     try {  
38.                             UtilTimerStack.push(_profileKey);  
39.                             listener.beforeResult(this, resultCode);  
40.                     }  
41.                     finally {  
42.                             UtilTimerStack.pop(_profileKey);  
43.                     }  
44.                 }  
45.             }  
46.   
47.             // now execute the result, if we're supposed to  
48.             // action與interceptor執行完畢，執行Result  
49.             if (proxy.getExecuteResult()) {  
50.                 executeResult();  
51.             }  
52.   
53.             executed = true;  
54.         }  
55.   
56.         return resultCode;  
57.     }  
58.     finally {  
59.         UtilTimerStack.pop(profileKey);  
60.     }  
61. }  

Java代碼  

1. resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);  

Java代碼  

1. public String intercept(ActionInvocation invocation) throws Exception {  
2.     String result = null;  
3.   
4.         before(invocation);  
5.         // 調用invocation的invoke()方法，在這里形成了遞歸調用  
6.         result = invocation.invoke();  
7.         after(invocation, result);  
8.   
9.         return result;  
10. }  

自己制作ssl證書：自己簽發免費ssl證書，為nginx生成自簽名ssl證書

    這里說下Linux 系統怎么通過openssl命令生成 證書。

  首先執行如下命令生成一個key
openssl genrsa -des3 -out ssl.key 1024
    然后他會要求你輸入這個key文件的密碼。不推薦輸入。因為以后要給nginx使用。每次reload nginx配置時候都要你驗證這個PAM密碼的。
    由于生成時候必須輸入密碼。你可以輸入后 再刪掉。

mv ssl.key xxx.key
openssl rsa -in xxx.key -out ssl.key
rm xxx.key
    然后根據這個key文件生成證書請求文件
openssl req -new -key ssl.key -out ssl.csr
    以上命令生成時候要填很多東西 一個個看著寫吧（可以隨便，畢竟這是自己生成的證書）

    最后根據這2個文件生成crt證書文件
openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt
    這里365是證書有效期 推薦3650哈哈。這個大家隨意。最后使用到的文件是key和crt文件。

    如果需要用pfx 可以用以下命令生成
openssl pkcs12 -export -inkey ssl.key -in ssl.crt -out ssl.pfx

    在需要使用證書的nginx配置文件的server節點里加入以下配置就可以了。
ssl on;
ssl_certificate /home/ssl.crt;
ssl_certificate_key /home/ssl.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
    然后重啟nginx就大功告成了

Nginx + https + 免費SSL證書配置指南

時間：2010-02-24 20:15:42   類別：技術   訪問：11,529 views   RSS 2.0   評論  

請參考 Nginx Wiki http://wiki.nginx.org/NginxHttpSslModule

生成證書

編輯 nginx.conf

OK, 完成了。但這樣證書是不被信任的，自己玩玩還行，要被信任請看下面。

以下內容轉載自
http://goo.gl/YOb5
http://goo.gl/Gftj

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容 請看SSL。

它是一個URI scheme（抽象標識符體系），句法類同http:體系。用于安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同 于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣 泛用于萬維網上安全敏感的通訊，例如交易支付方面。

1、自行頒發不受瀏覽器信任的SSL證書：
HTTPS的SSL證書可以自行頒發，Linux下的頒發步驟如下：

nginx.conf 的SSL證書配置，使用 api.bz_nopass.key，在啟動Nginx是無需輸入SSL證書密碼，而使用 api.bz.key 則需要輸入密碼：

自行頒發的SSL證書雖然能夠實現加密傳輸功能，但得不到瀏覽器的信任，會出現以下提示：