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了，只要使用統一的如下配置即可。
根據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這個父容器中了，看代碼。
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，代碼如下：
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。如下：
true
以上已經有了2種解決方案了，但在實際工程中，會包括很多配置，根據不同的業務模塊來劃分，所以我們一般思路是各負其責，明確邊界，Spring根容器負責所有其他非controller的Bean的註冊，而SpringMVC只負責controller相關的Bean的註冊。第三種方案如下：
Spring容器配置，排除所有@controller的Bean
SpringMVC容器配置，讓其只包括@controller的Bean
個人比較推薦第三種方案。引申一下，項目中使用事務的配置方案，也會在這種場景下失效，歸根結底也是由於2個容器的可見性問題導致，可以結合具體問題按照上面的思路進行查找原因！(——全文完——)
TAG:java吧 |