標籤：c style class blog code java
使用了listener監聽器來載入配置，一般在Struts+Spring+Hibernate的項目中都是使用listener監聽器的。如下
<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);
DispatcherServlet是一個Servlet,可以同時配置多個，每個 DispatcherServlet有一個自己的內容物件（WebApplicationContext），稱為子上下文（子容器），子上下文可以訪問 父上下文中的內容，但父上下文不能訪問子上下文中的內容。 它也儲存在 ServletContext中，key 是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名稱。當一 個Request對象產生時，會把這個子內容物件（WebApplicationContext）儲存在Request對象中，key是 DispatcherServlet.class.getName() + ".CONTEXT"。
可以使用工具類取出內容物件：RequestContextUtils.getWebApplicationContext(request);
說明 ：Spring 並沒有限制我們，必須使用父子上下文。我們可以自己決定如何使用。
方案一，傳統型：
父上下文容器中儲存資料來源、服務層、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，事情就簡單了，什麼麻煩事兒也沒有了。
