前言
SpringMVC提供了很多可拓展的组件,例如:参数解析器、拦截器、异常处理器等等。但是如果想要理解/找到这些组件工作的位置/时机,很多时候总是容易迷失在其层层调用的源码之中。因此才想从上帝视角来剖析它。而所谓上帝视角,就是回到SpringMVC的设计本身,来理解他。
DispatcherServlet
相信大家都认识这东西,作用啥的也就不多说了。但请先暂时记住这一点: 他是javax.servlet.Servlet。
环境准备
WebApplicationContext
什么是上下文
还记得以前做阅读理解题目的时候吗?老师经常说的一句话是:联系上下文。又比如,你跟淘宝客服聊天,有时候我们总是先把商品发给对方,然后再说这个有没有其他颜色之类的。而这些推动事情继续发展的“背景知识”就可以叫做上下文。
回到Spring,像环境配置、bean对象在哪里、事件发布等等,都属于上下文信息。即使,不是直接的进行参与,至少也要能够“联系”到对应的人来处理。例如,BeanFactory。如果从这个角度看的话,还能这样理解,他就是一个信息机构,有点像情报机构。你想要的东西他都能给你找来。实际上,我们在工作中,临时接入某个事情的时候,都需要进行交接/学习“上下文”。在了解事情的背景知识之后,我们才能进一步开展工作。
不过,由于Spring的上下文,是整个应用运行的上下文,因此Spring的上下文需要具备的背景知识比较庞杂,理解起来不容易。但我们可以从他的继承关系来理解他的能力。这里就不扩展了。
父子上下文
SpringMVC把上下文分为Servlet容器的上下文,和根应用上下文。这点可能有不少人知道。但是,为什么要这样分呢?先看下两个上下文的职责分工。
- Servlet上下文包含控制器、试图解析器,以及其他web相关的bean
- Root上下文,则包含中间层服务,数据源等。
可能有同学会问,为什么要多此一举呢?只使用一个上下文不行吗?还更容易理解。但是,有的情况下,我们的web应用可能不止提供http服务。例如:定时任务。定时任务跟Servlet有关系吗?
从设计原则上说,这种划分可能也是基于最少知识原则,降低系统的耦合,也为其可维护性埋下伏笔。简而言之,web上下文只管web相关的bean,应用上下文管其他与web无关的bean。
Root ApplicationContext怎么加载呢?
DispatcherServlet通过自己的上下文来提供web服务。并且该web上下文还有个父亲。我们很容易想到在DispatcherServlet创建/初始化时,创建一个web上下文并扫描相关的webBean。但是Root ApplicationContext增加加载呢?怎么衔接起来呢?
DispatcherServlet不就是一个servlet吗?通过ServletContext传递不就好了。但是什么时候创建呢?于是我们就需要到tomcat里面来了。
tomcat启动的时候,也有自己的上下文:ServletContext。这个时候,可能有同学要晕车。。其实,你回过头再理解一下上下文,或许就好了。这就类似于我们现实生活中,做不同的事情,所需要了解的背景知识不一样。如果你用SpringCloud,还有个Bootstrap ApplicationContex,可以自己理解一下,它又是干啥的。
当ServletContext初始化完成后,就会发布一个ServletContextEvent。这时只要我们实现ServletContextListener,即可收到通知。于是,我们便可借此机会初始化Root ApplicationContext,并放到ServletContext里面。
DispatcherServlet启动
DispatcherServlet有一个Web上下文,并且由他管理着所有的web相关的bean。这意味着,在DispatcherServlet具备提供服务的能力之前,我们需要先将这个上下文准备好。而之前说的,只是Root Application。
如果是你,你会怎么做呢?很容易想到就是在创建DispatcherServlet的时候对上下文进行初始化。只不过我们的DispatcherServlet本质上是Servlet,因此只需要跟随Servlet的生命周期函数就好。所以选择在javax.servlet.Servlet#init方法进行初始化。
实际的实现在:org.springframework.web.servlet.FrameworkServlet#initServletBean
要找到他的实际创建和刷新上下文,还是有点绕的,调用链路贴一下:
而org.springframework.web.servlet.DispatcherServlet#initStrategies方法就是从web上下文中获取DispatcherServlet所依赖的相关的webBean.
protected void initStrategies(ApplicationContext context) {
this.initMultipartResolver(context);
this.initLocaleResolver(context);
this.initThemeResolver(context);
this.initHandlerMappings(context);
this.initHandlerAdapters(context);
this.initHandlerExceptionResolvers(context);
this.initRequestToViewNameTranslator(context);
this.initViewResolvers(context);
this.initFlashMapManager(context);
}
DispatcherServlet内部的九大组件
从上面的初始化代码来看,有如下组件;
MultipartResolver:文件上传处理器
LocaleResolver:多语言解析器
ThemeResolver: 主题解析器,简单来说就是页面的整体样式。可参考文章
HandlerMapping: 处理器映射器,找到对应的处理器就靠他了
HandlerAdapter:处理器适配器
HandlerExceptionResolver:处理器异常解析器
RequestToViewNameTranslator:将请求翻译成视图名字的解释器
ViewResolver:视图解析器
FlashMapManager:FlashMap管理器。用于重定向请求的。FlashMap本身是一个Map,把跳转前的参数保存在FlashMap中。然后再将其作为Request的session属性进行设置。
从我们经常使用的@RequestMapping的方式声明一个Http接口的角度看,以上组件并不是完全必要的。因此这里不会讨论无关的组件。在这里提醒一下,spring的这些工具可能不止一个实现,不同的实现对应不同的使用场景。例如HandlerMapping的BeanNameUrlHandlerMapping,把bean的名字作为请求uri映射给该bean来处理请求。RequestMappingHandlerMapping则是通过@RequestMapping进行uri地址映射的。本次我们讨论的是与@RequestMapping相关的。
RequestMappingHandlerMapping需要什么信息?
- 他需要知道哪些对象有@RequestMapping注解,才能找到uri对应的处理方法。这意味着他需要对所有的bean进行遍历。
因此需要解析@RequestMapping,包括这些信息:可以处理的uri,以及各种限定条件。例如:该注解可以指定处理POST请求
- 他需要按照方法参数来进行参数解析,以便调用目标处理方法
因此他需要参数转换服务。例如:字符串转Date
RequestMappingHandlerMapping初始化
顺着上面的九大组件的初始化方法找:
> org.springframework.web.servlet.DispatcherServlet#initHandlerMappings
> org.springframework.web.servlet.DispatcherServlet#getDefaultStrategies
如果没有配置HandlerMapping,那么就会找到org.springframework.web.servlet包下的DispatcherServlet.properties,从这里面加载默认的HandlerMapping.
但这里还没完,因为RequestMappingHandlerMapping实现了InitializingBean接口。而实际上到这里,他也只是创建了这个对象,并没有对我们之前说的各种属性进行初始化。
在afterPropertiesSet方法会调用到下面这个方法
protected void initHandlerMethods() {
// 遍历bean工厂中所有beanName
for (String beanName : getCandidateBeanNames()) {
if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
// 处理候选bean:他会检查bean是否为Controller,如果是,还会注册到MappingRegistry,也即Mapping注册中心。所谓Mapping就是uri->handler
processCandidateBean(beanName);
}
}
handlerMethodsInitialized(getHandlerMethods());
}