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方法中，由此大約能夠想明白這個“階段監聽器”的道理了。
【編輯推薦】
