本人刚开始接触spring与springMVC不久，最开始配置service项目时遇到一个问题：在rootconfig下配置spring扫描bean的路径包含了controller，然后在webconfig中不配置扫描controller的路径，发现在tomcat启动时，确实初始化了controllerBean并且存放在了rootWebapplicationContext上。但是请求接口时却发现请求不到任何接口。如果在webconfig上配置controller扫描路径，就能请求到controller中的接口。但是做了一个测试，在某个控制器的构造器中写了控制台打印“111”，tomcat启动时会发现控制台打印了2次也就是说控制器bean被创建了两次。那么倒是怎么回事？
?
?
从网上的一些资料的做法看到，就是说rootconfig中配置扫描路径要排除controller的路径，在webconfig只扫描controller的路径，如果扫描了service，那么service的事务功能就失效了。具体原因说法不一，一种可靠说话是子上下文优先与父上下文，子上下文中的service没有事务功能。
?
?
后来查看源码大概了解其机制，下面一一阐述。
首先看到tomcat启动时控制台：
?图中1-2：是创建spring扫描的bean，存放在RootWebapplicationContext中
图中3：我们看到还有一个webapplicationContext，它的父上下文是RootWebapplicationContext
?
也就是说是一共有2个webapplicationContext，namespace为dispatcher-servlet是子上下文。
我们来看DispatcherServlet的父类FramworkServlet的configureAndRefreshWebApplicationContext方法
?
Debug发现?? 方法入参的wac就是 RootWebapplicationcontext，但是在这个方法中，getServletName为dispatcher-servlet，并通过setId以及setServletContext等等后面的几个方法把wac设置了namespace为dispatcher-sevlet的webapplicationContext，也就是说这个名叫namespace：dispatcher-servlet的子上下文取代了原先RootWebapplicationContext的地位，其parent为RootWebapplicationContext.
?
我们再来看Dispatcher-servlet的initHandlerMapping方法
?
?
?
?
这个时候的入参context就是子上下文名叫dispatcher-servlet的WebapplicationContext，从这里看出，初始化HandlerMappings只是从namespace：dispatcher-servlet的webapplicationContext中去取Bean；
?
按照我自己的理解，子上下文已经取代了root上下文的位置。所以spring在注入其他bean的时候，会先从dispatcher-servlet的webapplicationContext中去找对应的bean，如果找不到，才去其parent为rootWebapplicationContext中去找bean。这样也解释了，为什么webconfig扫描了service，service的事务功能的没有了。因为子上下文和父上下文中都存放了serviceBean。
?
得出结论：spring扫描与springMVC扫描避免重复。SpringMVC只用扫描控制器类的包。Spring扫描除控制器以外的类包
?
?