Springmvc 是基于servlet 规范来完成的一个请求响应模块,也是spring 中比较大的一个 模块,现在基本上都是零xml 配置了,采用的是约定大于配置的方式,所以我们的springmvc 也是采用这种零xml 配置的方式。
要完成这种过程,要解决两个问题:1、取代web.xml 配置 ,2、取代springmvc.xml 配置。 取代web.xml 配置在servlet 中有一个规范,就是当servlet 容器启动的时候会根据SPI 规范加载 META-INF/services 文件夹下面的javax.servlet.ServletContainerInitializer 文件,该文件下面的 类会实现javax.servlet.ServletContainerInitializer 接口。
SPI 也被称为服务接口扩展,(Service Provider Interface) 直译服务提供商接口, 不要被这个名字唬到了, 其实很好理解的一个东西: 就是根据Servlet厂商(服务提供商)提供要求的一个接口, 在固定的目录 (META-INF/services)放上以接口全类名 为命名的文件, 文件中放入接口的实现的 全类名,该类由我们自己实现,按照这种约定的方式(即SPI规范),服务提供商会 调用文件中实现类的方法, 从而完成扩展。
该类SpringServletContainerInitializer在启动的时候会被servlet 容器(例如tomcat)实例化,然后调用onStartup 方法,并且servlet 容器会收集实现了@HandlesTypes 注解里面的接口的类(WebApplicationInitializer),并且做为入参传入到onStartup 方法中,我们拿到set 容器中的类就可以反射调用接口里面的方法了,这是servlet 规范,该规范就能保证servlet 容器在启动的时候就会完成这些操作。Springmvc 就借助这一点完成了取代web.xml 的工作。
我们定义了一个类MyWebAppInitializer继承自AbstractAnnotationConfigDispatcherServletInitializer,最上层的接口其实就是WebApplicationInitializer,这个接口有两个重要实现getRootConfigClasses将RootConfig引入了进来,这个RootConfig就是父容器的配置类,相当于之前的spring.xml;另一个方法getServletConfigClasses引入进来了WebAppConfig,这个是是子容器的配置类,相当于之前的spring-mvc.xml。
父容器会对com.dsk下的包进行扫描,但是排除了类上注解为@RestController和@Controller的类。因为controller要交给springmvc自身的子容器去管理,父容器会管理一些@Service相关的类。
子容器会对com.dsk下的包进行扫描,但是只扫描了类上注解为@RestContrller和@Controller的类
相关的类介绍完之后,看下核心的onStartup方法,我们定义的MyWebAppInitializer与其父类的继承关系分别是MyWebAppInitializer-》AbstractAnnotationConfigDispatcherServletInitializer-》AbstractDispatcherServletInitializer-》AbstractContextLoaderInitializer-》WebApplicationInitializer
第一步继续会调用父类的onStartUp方法
第二步注册dispatcherServlet
我们再往下一层AbstractContextLoaderInitializer父类的onStartup方法,可以看到这一步就是注册监听器ContextLoaderListener,注册进servletContext,这个监听器的作用其实就是当servlet容器(例如tomcat)启动成功后,会调用监听器的contextInitialized方法。
这一步相当于在web.xml中配置了ContextLoaderListener,如下
registerContextLoaderListener方法中不只是注册了listener,还创建了父容器rootAppContext
创建父容器的方法createRootApplicationContext中,其实就是熟悉的AnnotationConfigWebApplicationContext,他将父容器也就是RootConfig注册进了BeanDefinitionRegistry中
总结registerContextLoaderListener方法做了两件事情
1、创建父容器,也就是spring的AnnotationConfigWebApplicationContext
2、将ContextLoaderListener加入到servletContet中,注意此时ContextLoaderListener持有父容器对象rootContext方法,目的是当servlet容器启动成功后,会通知到监听器,此时监听器会调用父容器的refresh方法,将类注入到spring容器中。
那么父类AbstractContextLoaderInitializer的onStartUp方法就看完了,回到AbstractDispatcherServletInitializer类
这一步就是将dispatcherServlet注册进servletContext中,并把上下文对象设置到了
dispatcherServlet 对象中,相当于web.xml的如下配置
这个方法registerDispacherServlet不止是将dispatcherServlet加入到了servletContext,同时也创建了子容器,可以看到这个子容器也是AnnotationConfigWebApplicationContext,只不过此时注册进来的类是WebAppConfig,子类会将带有@Controller的类扫描进来,注入到子容器中。
那么onStartUp方法就执行完了,做个总结:
一、registerContextLoaderListener(servletContext);
做了两件事情1、创建父容器,且listener中持有父容器对象;2、将ContextLoaderListener加入到ServletContext
二、registerDispatcherServlet(servletContext);
做了两件事情1、创建子容器,且dispatcherServlet中持有子容器对象;2、将DispatcherServlet加入到ServletContext;
ContextLoaderListener启动:
执行完onStartUp方法后,此时父容器和子容器还没有启动,因为并没有执行到他们的refresh方法,我们知道当servlet容器(tomcat启动成功后)会调用监听器ContextLoaderListener.contextInitialized方法,这里会启动spring容器,把spring上下文对象放入到了servletContext中
DispatcherServlet 的启动:
了解DispatcherServlet的生命周期的会知道,DispatcherServlet启动过程中会执行init()方法,在这里会进行springmvc子容器的启动
这里会从servletContext中获取父容器对象,并将子容器webApplicationContext的parent赋值为rootContext,然后执行子容器的refresh()方法。
在调用子容器的刷新方法前,这里会注册一个监听器(该监听会初始化springmvc所需信息),
ContextRefreshedEvent可以看到该监听器监听的是容器refreshed事件, 会在子容器的refresh方法中的finishRefresh中发布,这是spring的监听器模式。
子容器的refresh()方法最后一步,会发布事件触发监听器的执行
这里面的每一个方法不用太细看, 就是给SpringMVC准备初始化的数据, 为后续SpringMVC处理请求做准备基本都是从容器中拿到已经配置的Bean(RequestMappingHandlerMapping、
RequestMappingHandlerAdapter、HandlerExceptionResolver )放到dispatcherServlet中做准备。但是这些Bean又是从哪来的呢?? 回到我们的WebAppConfig使用的@EnableWebMvc,也就是这个注解取代了springmvc.xml
-
导入了DelegatingWebMvcConfiguration@Import(DelegatingWebMvcConfiguration.class)
-
DelegatingWebMvcConfiguration的父类就配置了这些Bean
-
SpringBoot也是用的这种方式;
总结:
- Tomcat在启动时会通过SPI注册 ContextLoaderListener和DispatcherServlet对象
a. 同时创建父子容器
i. 分别创建在ContextLoaderListener初始化时创建父容器设置配置类
ii. 在DispatcherServlet初始化时创建子容器设置配置类
- Tomcat在启动时执行ContextLoaderListener和DispatcherServlet对象的初始化方
法, 执行容器refresh进行加载
- 在子容器加载时 创建SpringMVC所需的Bean和预准备的数据:(通过配置类
@EnableWebMvc配置(DelegatingWebMvcConfiguration)------可实现WebMvcConfigurer进行定制扩展)
a. RequestMappingHandlerMapping,它会处理@RequestMapping 注解
b. RequestMappingHandlerAdapter,则是处理请求的适配器,确定调用哪个类的哪个方法,并且构造方法参数,返回值。
c. HandlerExceptionResolver 错误视图解析器
d. addDefaultHttpMessageConverters 添加默认的消息转换器(解析json、解析xml)等
- 子容器需要注入父容器的Bean时(比如Controller中需要@Autowired例如Service的Bean); 会先从子容器中找,没找到会去父容器中找。
一、Spring和SpringMVC为什么需要父子容器?不要不行吗?就实现层面来说不用子父容器也可以完成所需功能(参考:SpringBoot就没用子父容器)?
-
所以父子容器的主要作用应该是早期Spring为了划分框架边界。有点单一职责的味道service、dao层我们一般使用spring框架来管理、controller层交给springmvc管理
-
规范整体架构 使 父容器service无法访问子容器controller、子容器controller可以访问父容器 service
-
方便子容器的切换。如果现在我们想把web层从spring mvc替换成struts,那么只需要将springmvc.xml替换成Struts的配置文件struts.xml即可,而spring.xml不需要改变。
-
为了节省重复bean创建
二、是否可以把所有Bean都通过Spring容器来管理?(Spring的applicationContext.xml中配置全局扫描)?
不可以,这样会导致我们请求接口的时候产生404。 如果所有的Bean都交给父容器,SpringMVC在初始化HandlerMethods的时候(initHandlerMethods)无法根据Controller的handler方法注册HandlerMethod,并没有去查找父容器的bean;也就无法根据请求URI 获取到 HandlerMethod来进行匹配.
三、是否可以把我们所需的Bean都放入Spring-mvc子容器里面来管理(springmvc的springservlet.xml中配置全局扫描)?
可以 , 因为父容器的体现无非是为了获取子容器不包含的bean, 如果全部包含在子容器完全用
不到父容器了, 所以是可以全部放在springmvc子容器来管理的。虽然可以这么做不过一般应该是不推荐这么去做的,一般人也不会这么干的。如果你的项目里有用到事物、或者aop记得也需要把这部分配置需要放到Spring-mvc子容器的配置文件来,不然一部分内容在子容器和一部分内容在父容器,可能就会导致你的事务或者AOP不生效。 所以如果aop或事务如果不生效也有可能是通过父容器中的类(spring)去增强子容器的类(Springmvc),也就无法增强。
下个章节我们解析springmvc的请求源码流程。