要想很好理解這三個上下文的關係,需要先熟悉spring是怎樣在web容器中啓動起來的。spring的啓動過程其實就是其IoC容器的啓動過程,對於web程序,IoC容器啓動過程即是建立上下文的過程。
spring的啓動過程:
當我們的web服務啓動的時候,會根據web.xml配置文件的ContextLoaderListener類來初始化ApplicationContext,也就是我們的spring容器,然後spring
容器通過web.xml中配置的context-param的參數找到bean的配置文件,根據配置信息來創建bean.
首先,對於一個web應用,其部署在web容器中,web容器提供其一個全局的上下文環境,這個上下文就是ServletContext,其爲後面的spring IoC容器提供宿主環境;
其次,在web.xml中會提供有contextLoaderListener。在web容器啓動時,會觸發容器初始化事件,此時contextLoaderListener會監聽到這個事件,其contextInitialized方法會被調用,在這個方法中,spring會初始化一個啓動上下文,這個上下文被稱爲根上下文,即WebApplicationContext,這是一個接口類,確切的說,其實際的實現類是XmlWebApplicationContext。這個就是spring的IoC容器,其對應的Bean定義的配置由web.xml中的context-param標籤指定。在這個IoC容器初始化完畢後,spring以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE爲屬性Key,將其存儲到ServletContext中,便於獲取;
再次,contextLoaderListener監聽器初始化完畢後,開始初始化web.xml中配置的Servlet,這個servlet可以配置多個,以最常見的DispatcherServlet爲例,這個servlet實際上是一個標準的前端控制器,用以轉發、匹配、處理每個servlet請求。DispatcherServlet上下文在初始化的時候會建立自己的IoC上下文,用以持有spring mvc相關的bean。在建立DispatcherServlet自己的IoC上下文時,會利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先從ServletContext中獲取之前的根上下文(即WebApplicationContext)作爲自己上下文的parent上下文。有了這個parent上下文之後,再初始化自己持有的上下文。這個DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到,大概的工作就是初始化處理器映射、視圖解析等。這個servlet自己持有的上下文默認實現類也是mlWebApplicationContext。初始化完畢後,spring以與servlet的名字相關(此處不是簡單的以servlet名爲Key,而是通過一些轉換,具體可自行查看源碼)的屬性爲屬性Key,也將其存到ServletContext中,以便後續使用。這樣每個servlet就持有自己的上下文,即擁有自己獨立的bean空間,同時各個servlet共享相同的bean,即根上下文(第2步中初始化的上下文)定義的那些bean。
說完了spring上下文的初始化過程,這三個上下文的關係應該就瞭解了。如還是不太清楚,我就愛莫能助了,只能自行看代碼去了。
===============================================================================================================
最近在做項目時牽扯到有關父子上下文的概念。
何爲父子上下文呢?
父上下文:
使用listener監聽器來加載配置文件,如下:
1 2 3 | < listener > < listener-class >org.springframework.web.context.ContextLoaderListener</ listener-class > </ listener > |
Spring 會創建一個WebApplicationContext上下文,稱爲父上下文(父容器),保存在 ServletContext中,key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE的值。
可以使用Spring提供的工具類取出上下文對象:WebApplicationContextUtils.getWebApplicationContext(ServletContext);
子上下文:
使用Spring MVC 來處理攔截相關的請求時,會配置DispatchServlet:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | < servlet > < servlet-name >dispatcherServlet</ servlet-name > < servlet-class >org.springframework.web.servlet.DispatcherServlet </ servlet-class > < init-param > < param-name >contextConfigLocation</ param-name > < param-value >/WEB-INF/applicationContext-mvc.xml</ param-value > </ init-param > < load-on-startup >1</ load-on-startup > </ servlet > < servlet-mapping > < servlet-name >dispatcherServlet</ servlet-name > < url-pattern >/</ url-pattern > </ servlet-mapping > |
每個DispatchServlet會有一個自己的上下文,稱爲子上下文,它也保存在 ServletContext中,key 是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名稱。當一 個Request對象產生時,會把這個子上下文對象(WebApplicationContext)保存在Request對象中,key是 DispatcherServlet.class.getName() + ".CONTEXT"。
可以使用工具類取出上下文對象:RequestContextUtils.getWebApplicationContext(request);
父上下文(父容器)和子上下文(子容器)的訪問權限:
子上下文可以訪問父上下文中的bean,但是父上下文不可以訪問子上下文中的bean。
父上下文使用與否
方案一,傳統型:
父上下文容器中保存數據源、服務層、DAO層、事務的Bean。
子上下文容器中保存Mvc相關的Action的Bean.
事務控制在服務層。
由於父上下文容器不能訪問子上下文容器中內容,事務的Bean在父上下文容器中,無法訪問子上下文容器中內容,就無法對子上下文容器中Action進行AOP(事務)。
當然,做爲“傳統型”方案,也沒有必要這要做。
方案二,激進型:
Java世界的“面向接口編程”的思想是正確的,但在增刪改查爲主業務的系統裏,Dao層接口,Dao層實現類,Service層接口,Service層實現類,Action父類,Action。再加上衆多的O(vo\po\bo)和jsp頁面。寫一個小功能 7、8個類就寫出來了。 開發者說我就是想接點私活兒,和PHP,ASP搶搶飯碗,但我又是Java程序員。最好的結果是大項目能做好,小項目能做快。所以“激進型”方案就出現了-----沒有接口、沒有Service層、還可以沒有衆多的O(vo\po\bo)。那沒有Service層事務控制在哪一層?只好上升的Action層。
本文不想說這是不是正確的思想,我想說的是Spring不會限制你這樣做。
由於有了父子上下文,你將無法實現這一目標。解決方案是只使用子上下文容器,不要父上下文容器 。所以數據源、服務層、DAO層、事務的Bean、Action的Bean都放在子上下文容器中。就可以實現了,事務(註解事務)就正常工作了。這樣纔夠激進。
總結:不使用listener監聽器來加載spring的配置文件,只使用DispatcherServlet來加載spring的配置,不要父子上下文,只使用一個DispatcherServlet,事情就簡單了,什麼麻煩事兒也沒有了。
Java--大項目能做好--按傳統方式做,規規矩矩的做,好擴展,好維護。
Java--小項目能做快--按激進方式做,一週時間就可以出一個版本,先上線接受市場(用戶)的反饋,再改進,再反饋,時間就是生命(成本)。