JSF請求處理過程詳解

JSF應用中，在web.xml裡面配置了一個Servlet，叫做javax.faces.webapp.FacesServlet，於是可以知道，查看、了解一個請求的處理過程可以從這裡開始。從官方網站上下載JSF的源代碼，項目名比較古怪，叫做“mojarra”，我看的版本是1.2_12_b01。裡面包含了兩個子項目，一個是jsf-api，裡面大多是接口以及少量關鍵類。另外一個項目叫做jsf-ri，對著這個"ri"邪念了半天之後，終於在兄弟提醒之下想明白了是reference implementation的意思。jsf-api是JavaEE標准的一部分，裡面的類型包名都是以javax.faces開頭的，而jsf-ri項目是sun針對JSF標准的一個參考實現，裡面的類型的包名都是以com.sun.faces開頭的。

FacesServlet初始化FacesServlet#init）

JSF請求處理過程中，系統啟動的時候，會初始化FacesServlet，調用其中的init方法。裡面主要做了兩件事情，一個是初始化FacesContextFactory，另外一個是初始化Lifecycle對象。在jsf-api項目中，FacesServlet類是一個Servlet接口的實現類，而FacesContextFactory和Lifecycle都是接口。在jsf-ri項目中有這兩個接口的實現類，分別是com.sun.faces.context.FacesContextFactoryImpl和com.sun.faces.lifecycle.LifecycleImpl類。一個想當然的事實：FacesServlet初始化的時候要根據一些配置來判斷具體的FacesContextFactory和Lifecycle實現類是什麼，也就是在這裡，“JSF標准”和“JSF實現”接軌了。想來MyFaces等等的其他JSF實現應該不外乎兩種方式，一種是改變FacesServlet的init方法中需要用到的配置的值，於是啟用自己的FacesContextFactory實現和Lifecycle實現，後面的處理過程就全部走自己的邏輯了。第二種方法笨一點，可能性不大，就是把FacesServlet覆蓋替換掉，其中也不需要讀什麼配置了，直接使用自己的實現類即可——不過這種做法估計不符合JSF規范，想來只有我等蝦米民眾能做的出來。主要代碼如下：

1 facesContextFactory = (FacesContextFactory)FactoryFinder.
getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);  
2   
3 LifecycleFactory lifecycleFactory = (LifecycleFactory)FactoryFinder.
getFactory(FactoryFinder.LIFECYCLE_FACTORY); 

回頭再來看初始化的結果，FacesContextFactory很明顯是用來生產FacesContext這麼個東西的。而FacesContext可以看做是一個RequestWrapper注意這個FaceContext和ServletContext不一樣，ServletContext是一個Web應用只有一個的全局對象，對應的是一個Web application，而一個FacesContext對應的是一個request,另外，RequestWrapper這個說法不嚴格，實際上FacesContext裡面也包裝了ServletContext、Response等）。而LifeCycle可以看做是一個過濾器鏈類似於servlet規范裡面的Filter Chain）。於是，整個JSF請求處理過程，實際上就是包裝成為FaceContext的用戶請求，通過類似於一個Filter Chain的LifeCycle的過程。

這總覽，很明顯是看FacesServlet的service方法。在FacesServlet的初始化過程中，構造出了全局的FacesContextFactory對象和LifeCycle對象。可以把FacesContextFactory看做是一個“請求包裝工廠”，於是很明顯，每當一個請求到達FacesServlet的時候，第一步便是拿著請求，到包裝工廠裡面包裝一下，而包裝的結果就是一個FacesContext。代碼如下：

FacesContext context = facesContextFactory.getFacesContext(servletConfig.getServletContext(), request, response, lifecycle);

在包裝過程中，實際上是創建了一個com.sun.faces.context.FacesContextImpl對象，FacesContextImpl類繼承了jsf-api項目中的javax.faces.context.FacesContext。FacesContextImpl的構造方法的第一個參數是一個叫做ExternalContext的接口的實現，查看其源代碼，可以看到ExternalContextImpl類耦合了Servlet API，而FacesContextImpl與Servlet API無關。實際上，在這裡，做到了JSF可以不僅僅使用在Servlet環境中，正如ExternalContext接口的注釋中所說，在Servlet環境中使用JSF和在Portlet環境中使用JSF的不同，實際上就是使用了不同的ExternalContext。在FacesContextFactoryImpl中構造FacesContextImpl的代碼如下：

FacesContext ctx = new FacesContextImpl  
     (new ExternalContextImpl((ServletContext) sc,  
     (ServletRequest) request,(ServletResponse) response),  
      lifecycle); 

FacesContextImpl的構造方法中，還做了另外一件事情，就是根據配置確定了RenderKitFactory，顯然不同的RenderKitFactory可以產生不同的RenderKit，而不同RenderKit對象是針對不同客戶端的，所以對於浏覽器、移動設備等等，會有不同的RenderKit。FacesContextImpl的構造方法中代碼如下：

this.externalContext = ec;  
setCurrentInstance(this);  
this.rkFactory = (RenderKitFactory)FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY); 

在代碼中我們經常使用FacesContext.getCurrentInstance()這個靜態方法來獲取與當前請求對應的FacesContext對象，實際上是在FacesContext類裡面有一個靜態的ThreadLocal對象用來存放了當前請求線程對應的FacesContext對象，於是上面的代碼中setCurrentInstance(this)就是把當前構造出來的這個FacesContext對象放到了ThreadLocal裡面。

FacesContext創建出來以後，正如上面所說，要讓他經過LifeCycle這個“Filter Chain”的逐步處理了。那麼，Filter Chain裡面放的是一個一個Filter，那麼LifeCycle這個Chain裡面放的是什麼呢？答案是Phases。

FacesServlet讓FaceContext通過LifeCycle的處理，分成了兩個部分。一個部分是調用LifeCycle的execute方法，執行邏輯，第二個部分是調用LifeCycle的render方法，呈現響應。FacesServlet.service中代碼如下：

lifecycle.execute(context);  
lifecycle.render(context); 

在LifeCycleImpl這個實現中，存放了一個Phase對象的數組，存放了7個Phase。其中第一個是null，然後依次是視圖重建、應用請求值、驗證、更新模型值、執行應用程序、呈現響應。在execute方法中，調用了從視圖重建開始到執行應用程序為止的5個Phase，而在render方法中，調用了最後一個Phase，也就是呈現響應。在LifeCycleImpl類中，代碼如下：

//The Phase instance for the render() method  
    private Phase response = new RenderResponsePhase();  
 
    // The set of Phase instances that are executed by the execute() method  
    // in order by the ordinal property of each phase  
    private Phase[] phases = {  
        null, // ANY_PHASE placeholder, not a real Phase  
        new RestoreViewPhase(),  
        new ApplyRequestValuesPhase(),  
        new ProcessValidationsPhase(),  
        new UpdateModelValuesPhase(),  
        new InvokeApplicationPhase(),  
        response  
    }; 

在Servlet Filter中，可以由每一個Filter來決定是否要調用下一個Filter，從而決定是否讓請求繼續通過Filter Chains中的後續Filter，是鏈式調用的過程。而在LifeCycle的execute方法中，是用一個for循環順序執行幾個Phase。在每一個Phase執行完之後，都會檢查FaceContext對象中是否設置了停止後續處理直接呈現響應的標志renderResponse）或者已經完成了響應無需後續處理也不需要經過呈現響應階段了responseComplete），如果標志為true，那麼就不再執行後續Phase。

LifeCycleImpl的execute方法主要代碼如下：

for (int i = 1, len = phases.length -1 ; i < len; i++) { // Skip ANY_PHASE placeholder  
 
             if (context.getRenderResponse() ||  
                 context.getResponseComplete()) {  
                 break;  
             }  
   
            phases[i].doPhase(context, this, listeners.listIterator());  
   
  } 

在LifeCycle的render方法中，也會檢查FacesContext的responseComplete狀態，如果為true，那麼就不再執行render Phase。於是我們此刻知道了在我們自己所寫的一些代碼或者JSF庫裡面的一些代碼中，調用FacesContext的responseComplete方法和renderResponse得作用原理。render方法主要代碼如下：

if (!context.getResponseComplete()) {  
       response.doPhase(context, this,listeners.listIterator());  
 } 

另外注意，Phase這個概念、接口，以及幾個實現，都是jsf-ri項目中的，而在jsf-api中不存在Phase這個概念。所以，LifeCycle是JSF標准的內容，而通過幾個Phase來處理請求這種實現是sun的參考實現的做法。

最後，我們在JSF請求處理過程中可以看到對於每一個phase都調用了doPhase方法，同時把LifeCycle和FacesContext當做參數傳入了。值得注意的是，所謂的phaseListener，也傳入了phase的doPhase方法中，由此大約能夠想明白這個“階段監聽器”的道理了。

1. 使用Acegi保護JSF應用程序
2. JSF的技術與組件
3. JSF開發問題和解決
4. 淺析對JSF項目的單元測試
5. Facelets專為JSF設計的視圖技術