spring父子容器

Spring 和SpringMVC 的父子容器關係 Spring和SpringMVC做爲Bean管理容器和MVC層的默認框架，已被衆多WEB應用採用，而實際使用時，因爲有了強大的註解功能，不少基於XML的配置方式已經被替代，可是在實際項目中，同時配置Spring和SpringMVC時會出現一些奇怪的異常，好比Bean被屢次加載，屢次實例化，或者依賴注入時，Bean不能被自動注入，可是明明你已經將該Bean註冊了的。找緣由仍是要看問題的根源，咱們從容器提及。 在Spring總體框架的核心概念中，容器是核心思想，就是用來管理Bean的整個生命週期的，而在一個項目中，容器不必定只有一個，Spring中能夠包括多個容器，並且容器有上下層關係，目前最多見的一種場景就是在一個項目中引入Spring和SpringMVC這兩個框架，其實就是2個容器，Spring是根容器，SpringMVC是其子容器，而且在Spring根容器中對於SpringMVC容器中的Bean是不可見的，而在SpringMVC容器中對於Spring根容器中的Bean是可見的，也就是子容器能夠看見父容器中的註冊的Bean，反之就不行。理解這點很重要，由於這是一個規則，是Spring本身設定的，可是往下看，咱們會發現有些地方它並不默認使用這個規則。 當咱們使用註解時，對於Bean註冊這個功能的實現就不須要在給每一個Bean配置XML了，只要使用統一的以下配置便可。 1 根據Spring提供的參考手冊，該配置的功能是掃描默認包下的全部的@Component註解，而且自動註冊到容器中，同時也掃描 @Controller， @Service，@Respository這三個註解，他們是繼承自@Component。 除了以上咱們使用的掃描配置，在項目中咱們常常見到的就是這個配置，其實有了以上的配置，這個是能夠省略掉的。 還有一個SpringMVC相關的是配置，通過驗證，這個是必需要配置的，由於它是和@RequestMapping結合使用的，這裏補充下SpringMVC框架相關的知識點。 HandlerMapping，是SpringMVC中用來處理Request請求URL到具體Controller的，其自身也分紅不少種類； HandlerAdapter，是SpringMVC中用來處理具體請求映射到具體方法的，其自身也分不少種類； @RequestMapping這個註解的主要目的就是對具體的Controller和方法進行註冊，以方便HandlerMapping用來處理請求的映射。可是@RequestMapping須要結合使用才能生效。 好了，有了以上基礎知識的鋪墊，咱們看下如今這樣的一個使用場景中，Spring與SpringMVC的容器衝突的緣由在那裏！ Spring配置文件applicationContext.xml，SpringMVC配置文件applicationContext-MVC.xml，這樣項目中就有2個容器了，配置方式A，以下： applicationContext.xml中配置了，負責全部須要註冊的Bean的掃描工做，applicationContext-MVC.xml中配置，負責springMVC相關注解的使用，啓動項目發現，springMVC失效，沒法進行跳轉，開啓log的DEBUG級別進行調試，發現springMVC容器中的請求好像沒有映射到具體controller中； 配置方式B，以下： 爲了快速驗證效果，將掃描配置到applicationContext-MVC.xml中，重啓後，驗證成功，springMVC跳轉有效。 要想查看具體緣由，翻看源碼，從springMVC的DispatcherServlet開始看，在一個請求進來以後，發生了什麼？漫長的查看以後，找到緣由，以下。 springMVC初始化時，會尋找全部當前容器中的全部@Controller註解的Bean，來肯定其是不是一個handler，而當前容器springMVC中註冊的Bean中並無@Controller註解的，注意，上面說起的配置方式A，全部的@Controller配置的Bean都註冊在Spring這個父容器中了，看代碼。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 protected void initHandlerMethods() { if (logger.isDebugEnabled()) { logger.debug("Looking for request mappings in application context: " + getApplicationContext()); } String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ? BeanFactoryUtils.beanNamesForTypeIncludingAncestors(getApplicationContext(), Object.class) : getApplicationContext().getBeanNamesForType(Object.class)); for (String beanName : beanNames) { if (isHandler(getApplicationContext().getType(beanName))){ detectHandlerMethods(beanName); } } handlerMethodsInitialized(getHandlerMethods()); } 在方法isHandler中會判斷當前bean的註解是不是controller，代碼以下： 1 2 3 protected boolean isHandler(Class beanType) { return AnnotationUtils.findAnnotation(beanType, Controller.class) != null; } 在配置方式B中，springMVC容器中包括了全部的@Controller註解的Bean，因此天然就能找到了。 以上是緣由，解決辦法是什麼？注意看initHandlerMethods()方法中，detectHandlerMethodsInAncestorContexts這個Switch，它主要控制從那裏獲取容器中的bean，是否包括父容器，默認是不包括的。因此解決辦法是有的，即在springMVC的配置文件中配置HandlerMapping的detectHandlerMethodsInAncestorContexts屬性爲true便可（這裏須要根據具體項目看使用的是哪一種HandlerMapping），讓其檢測父容器的bean。以下： 1 2 3 4 5 true 以上已經有了2種解決方案了，但在實際工程中，會包括不少配置，根據不一樣的業務模塊來劃分，因此咱們通常思路是各負其責，明確邊界，Spring根容器負責全部其餘非controller的Bean的註冊，而SpringMVC只負責controller相關的Bean的註冊。第三種方案以下： Spring容器配置，排除全部@controller的Bean 1 2 3 SpringMVC容器配置，讓其只包括@controller的Bean 1 2 3 我的比較推薦第三種方案。引伸一下，項目中使用事務的配置方案，也會在這種場景下失效，歸根結底也是因爲2個容器的可見性問題致使，能夠結合具體問題按照上面的思路進行查找緣由！ 引用一下海濤的博客中的一張圖。 原圖地址http://jinnianshilongnian.iteye.com/blog/1602617 轉載開濤博客