Spring和SpringMVC容器关系初窥

Posted 2021-05-01 畅游DT时代

简介

在Spring整体框架的核心概念中，容器的核心思想是管理Bean的整个生命周期。但在一个项目中，Spring容器往往不止一个，最常见的场景就是在一个项目中引入Spring和SpringMVC这两个框架，其本质就是两个容器：Spring是父容器，SpringMVC是其子容器。关于这两个容器的创建、联系及区别也正是本文所关注的问题。

Spring和SpringMVC作为Bean管理容器和MVC层的默认框架，已被众多Web应用采用。但是在实际应用中，初级开发者常常会因对Spring和SpringMVC的配置失当导致一些奇怪的异常现象，比如Controller的方法无法拦截、Bean被多次加载等问题，这种情况发生的根本原因在于开发者对Spring容器和SpringMVC容器之间的关系了解不够深入，这也正是本文要阐述的问题。

Spring容器，SpringMVC容器与ServletContext之间的关系

在Web容器中配置Spring时，你可能已经司空见惯于web.xml文件中的以下配置代码，下面我们以该代码片段为基础来了解Spring容器、SpringMVC容器与ServletContext之间的关系。要想理解这三者的关系，需要先熟悉Spring是怎样在Web容器中启动起来的。Spring的启动过程其实就是其Spring IOC（控制反转）容器的启动过程。特别地，对于Web程序而言，IOC容器启动过程即是建立上下文的过程。

Spring的启动过程

什么是ServletContext？对于一个Web应用，其部署在Web容器中，Web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的Spring IoC容器提供宿主环境。web.xml中会提供有contextLoaderListener，在web容器启动时，会触发容器初始化事件，此时contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，Spring会初始化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext。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上下文，用以持有SpringMVC相关的bean。特别地，在建立DispatcherServlet自己的IoC上下文前，会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文。有了这个parent上下文之后，再初始化自己持有的上下文。这个DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到，其工作就是初始化处理器映射、视图解析等。这个Servlet自己持有的上下文默认实现类也是mlWebApplicationContext，初始化完毕后，Sring以与Servlet的名字相关(此处不是简单的以Servlet名为Key，而是通过一些转换，具体可自行查看源码)的属性为属性Key，也将其存到ServletContext中，以便后续使用。

大致的启动流程图：

Spring容器与SpringMVC容器联系与区别

ContextLoaderListener中创建Spring容器主要用于整个Web应用程序需要共享的一些组件，比如DAO、数据库的ConnectionFactory等；而由DispatcherServlet创建的SpringMVC的容器主要用于和该Servlet相关的一些组件，比如Controller、ViewResovler等。它们之间的关系如下：

1.作用范围

子容器(SpringMVC容器)可以访问父容器(Spring容器)的Bean，父容器(Spring容器)不能访问子容器(SpringMVC容器)的Bean。也就是说，当在SpringMVC容器中getBean时，如果在自己的容器中找不到对应的bean，则会去父容器中去找，这也解释了为什么由SpringMVC容器创建的Controller可以获取到Spring容器创建的Service组件的原因。

2.具体实现

在Spring的具体实现上，子容器和父容器都是通过ServletContext的setAttribute方法放到ServletContext中的。但是，ContextLoaderListener会先于DispatcherServlet创建ApplicationContext，DispatcherServlet在创建ApplicationContext时会先找到由ContextLoaderListener所创建的ApplicationContext，再将后者的ApplicationContext作为参数传给DispatcherServlet的ApplicationContext的setParent()方法。也就是说，子容器的创建依赖于父容器的创建，父容器先于子容器创建。在Spring源代码中，你可以在FrameServlet.Java中找到如下代码：

其中，wac即为由DisptcherServlet创建的ApplicationContext，而parent则为有ContextLoaderListener创建的ApplicationContext。此后，框架又会调用ServletContext的setAttribute()方法将wac加入到ServletContext中。

Spring容器与SpringMVC容器的配置

在Spring整体框架的核心概念中，容器是核心思想，就是用来管理Bean的整个生命周期的，而在一个项目中，容器不一定只有一个，Spring中可以包括多个容器，而且容器间有上下层关系，目前最常见的一种场景就是在一个项目中引入Spring和SpringMVC这两个框架，其实就是两个容器：Spring是根容器，SpringMVC是其子容器。在上文中，我们提到，SpringMVC容器可以访问Spring容器中的Bean，Spring容器不能访问SpringMVC容器的Bean。但是，若开发者对Spring容器和SpringMVC容器之间的关系了解不够深入，常常会因配置失当而导致同时配置Spring和SpringMVC时出现一些奇怪的异常，比如Controller的方法无法拦截、Bean被多次加载等问题。

在实际工程中，一个项目中会包括很多配置，根据不同的业务模块来划分，我们一般思路是各负其责，明确边界，即：Spring根容器负责所有其他非controller的Bean的注册，而SpringMVC只负责controller相关的Bean的注册，下面我们演示这种配置方案。

1.Spring容器配置

Spring根容器负责所有其他非controller的Bean的注册：

（注意图中<context:exclude-filter>标签是除去对Controller层的扫描）

2.SpringMVC容器配置

SpringMVC只负责controller相关的Bean的注册，其中@ControllerAdvice用于对控制器进行增强，常用于实现全局的异常处理类：

在<context:component-scan>中可以添加use-default-filters，Spring配置中的use-default-filters用来指示是否自动扫描带有@Component、@Repository、@Service和@Controller的类。默认为true，即默认扫描。如果想要过滤其中这四个注解中的一个，比如@Repository，可以添加<context:exclude-filter/>子标签，如下：

而把use-default-filters设定为false，子标签为<context:include-filter/>实现了添加扫描Repository注解的功能

（注意use-default-filters true与false的对比，以及子标签<context:include-filter/>与<context:exclude-filter/>的对比）

Spring容器和SpringMVC容器的配置失当带来问题

关于Spring的AOP：AOP（Aspect Oriented Programming），即面向切面编程，可以说是OOP（Object Oriented Programming，面向对象编程）的补充和完善。OOP引入封装、继承、多态等概念来建立一种对象层次结构，用于模拟公共行为的一个集合。不过OOP允许开发者定义纵向的关系，但并不适合定义横向的关系，例如日志功能。日志代码往往横向地散布在所有对象层次中，而与它对应的对象的核心功能毫无关系对于其他类型的代码，如安全性、异常处理和透明的持续性也都是如此，这种散布在各处的无关的代码被称为横切（cross cutting），在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。

AOP技术恰恰相反，它利用一种称为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。使用"横切"技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处基本相似，比如权限认证、日志、事物。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。Spring中AOP代理由Spring的IOC容器负责生成、管理，其依赖关系也由IOC容器负责管理。因此，AOP代理可以直接使用容器中的其它bean实例作为目标，这种关系可由IOC容器的依赖注入提供。

AOP编程其实是很简单的事情，纵观AOP编程，程序员只需要参与三个部分：

1. 定义普通业务组件

2. 定义切入点，一个切入点可能横切多个业务组件

3. 定义增强处理，增强处理就是在AOP框架为普通业务组件织入的处理动作

这里不准备把Spring-AOP技术展开来说，简单的介绍是为了更好理解下面的内容和例子。

问题描述：

在一个项目中，想使用Spring AOP在Controller中切入一些逻辑，但发现不能切入到Controller的中，但可以切入到Service中。最初的配置情形如下：

1). Spring的配置文件application.xml包含了开启AOP自动代理、Service扫描配置以及Aspect的自动扫描配置，如下所示：

2). Spring MVC的配置文件spring-mvc.xml主要内容是Controller层的自动扫描配置。

3). 增强代码为如下:

4). 需要被代理的Controller如下:

解决方案：

因为Spring的Bean扫描和Spring-MVC的Bean扫描是分开的, 两者的Bean位于两个不同的Application, 而且Spring-MVC的Bean扫描要早于Spring的Bean扫描, 所以当Controller Bean生成完成后, 再执行Spring的Bean扫描,Spring会发现要被AOP代理的ControllerBean已经在容器中存在,父容器是无法访问子容器的，所以就拦截不到，配置AOP就无效了。我们只需要在SpringMVC的配置文件中添加Aspect的自动扫描配置即可。

-END-

声明：

本文为中国联通网研院网优网管部IT技术研究团队独家提供。

如需转载或合作，请联系管理员（[e-mail]）

---

长按既可添加关注

---