深入理解SpringMvc 启动流程
彻底搞懂 HandlerMapping和HandlerAdapter
知识点的回顾:
当Tomcat接收到请求后会回调Servlet的service方法,一开始入门Servlet时,我们会让自己的Servlet去实现HttpServlet接口,重写它的doGet()和doPost()方法
在SpringMvc中,SpringMvc的核心组件DispatcherSerlvet的继承图如上,可以看到上图,其实这个DispatcherServlet终究还是一个Servlet
我们追踪一下他的生命周期创建过程, 首先是说Servlet的创建时机,其实是存在两种情况的, 这取决于.setLoadOnStartup(1);设置的启动级别,当然一般都会设置成正数,表示当容器启动时实例化Servlet
于是Tomcat实例化Servlet,Servlet被初始化时首先被回调的方法是init()这大家都知道的,但是SpringMvc提供的DispatcherServlet中存在一个静态块,源码如下: 这个静态块干了什么事呢? 读取的是class path 下面的 DispatcherServlet.properties
static {
// Load default strategy implementations from properties file.
// This is currently strictly internal and not meant to be customized
// by application developers.
try {
// todo 它读取的是class path 下面的 DispatcherServlet.properties 配置文件
// todo resource/web/servlet/DispatcherServlet.properties
// todo 将这些默认的实现信息，封装进了Properties defaultStrategies
ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
}
catch (IOException ex) {
throw new IllegalStateException("Could not load '" + DEFAULT_STRATEGIES_PATH + "': " + ex.getMessage());
}
}
那问题来了,这个配置文件到底存放的什么? 让DispatcherServlet如此迫切的去加载? 我们文件贴在下面,可以看到存放的是一些全类名,这些是DiapacherServlet针对不同策略接口提供的八个默认的实现,当在上下文中没有匹配到程序员添加的这些实现时，就会使用这些默认的实现
# Default implementation classes for DispatcherServlet's strategy interfaces.
# Used as fallback when no matching beans are found in the DispatcherServlet context.
# Not meant to be customized by application developers.
# todo 这里存在 DiapacherServlet策略接口的八个默认的实现
# todo 当在上下文中没有匹配到程序员添加的这些实现时，就会使用这些默认的实现
org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver
org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping
org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver,\
org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\
org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator
org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver
org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager
好吧, 虽然这也不算跑题,但是我们还是回到DispatcherServlet的init()方法,其实去这个DispatcherServlet中是找不到这个init()方法的, 那这个方法在哪里了呢? 其实就在他的祖父类HttpServletBean中,源码如下:
意图很明确,前面用来初始化环境参数,后者调用 initServletBean();
@Override
public final void init() throws ServletException {
if (logger.isDebugEnabled()) {
logger.debug("Initializing servlet '" + getServletName() + "'");
}
// Set bean properties from init parameters.
// todo 设置初始化参数
PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);
if (!pvs.isEmpty()) {
try {
BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);
ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());
bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment()));
initBeanWrapper(bw);
bw.setPropertyValues(pvs, true);
}
catch (BeansException ex) {
if (logger.isErrorEnabled()) {
logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);
}
throw ex;
}
}
// Let subclasses do whatever initialization they like.
// todo 初始化SerlvetBean
initServletBean();
if (logger.isDebugEnabled()) {
logger.debug("Servlet '" + getServletName() + "' configured successfully");
}
}
initServletBean(); 见名知意,初始化ServletBean,说白了就是想去初始化DispatcherServlet呗,跟进去查看,不出意料,他是个抽象方法,跟进它的实现类
他的实现类是FrameworkServlet,进去跟进,看他去创建应用的上下文,但是如果上下文已经被初始化了,他是不会重复创建上下文的
我们继续跟进它的onRefresh()方法,同样这个方法是一个抽象方法,而它是实现就是我们关注的DispatcherServlet,源码如下: 在下面做了很多事,我们还是仅仅关注两点,初始化了handlerMapping和handlerAdapater
protected void onRefresh(ApplicationContext context) {
// todo 进行跟进，方法就在下面
initStrategies(context);
}
protected void initStrategies(ApplicationContext context) {
// todo 初始化和文件上传相关的解析器
initMultipartResolver(context);
initLocaleResolver(context);
initThemeResolver(context);
/**
* todo 初始化处理器映射器,这是我们看到重点
* todo 什么是处理器映射器?
* todo Controller在Spring中有多种情况, 那当一个用户的请求到来时, 如何进一步找到哪一种Controller来处理用户的请求呢?
* todo 这一步就是通过处理器映射器完成的
* todo 说白了, 通过处理器映射器我们可以找到那个处理当前请求的特定的组件, 我们称它为handler
* todo 但是这之间存在一个问题,就是说,这个handler到底是方法级别的,还是类级别的我们是不知道的,只能说,这个handler就肯定能处理这次请求而已
*/
initHandlerMappings(context);
initHandlerAdapters(context);
initHandlerExceptionResolvers(context);
initRequestToViewNameTranslator(context);
initViewResolvers(context);
initFlashMapManager(context);
}
到现在为止,本位关注的两个组件其实就完成了初始化了, 下一个问题就来了,什么时候使用他们呢?
那就得从Servlet的service()方法说起了,大家都知道这个方法会在Serlvet每一次收到请求时就会被回调一次,再回想我们原来是怎么变成来着? 但是后来我们都直接实现HttpServlet接口,然后重写他们的doGet()和doPost()来实现我们自己的Servlet, 那SpringMvc是怎么做的呢?
源码如下:
@Override
protected final void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
@Override
protected final void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
都是通过processRequest(request, response);来实现的,我们往下追踪这个方法,最终也是不出所料,我们来到了DispacherServlet中
我截取部分源码如下:
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
//异步编程
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
//检查请求中是否存在文件上传的操作
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
//todo 确定当前请求的处理程序,跟进去
//todo 换句话说就是 推断Controller的类型, Controller存在三种类型
// todo 跟进去看看这个handlerMapping的获取方式
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
// todo 用到了适配器设计模式，
// todo 如果 上面的HandlerExecutionChain 是bean类型， 经过这个方法后将被设置成bean
// todo 如果 上面的HandlerExecutionChain 是 method 类型， 经过这个方法后将被设置成吗method
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (logger.isDebugEnabled()) {
logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
}
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
同样的,我们只是关注上面的两点,看看SpringMvc是如何玩转HandlerMapping和HandlerAdapter的, 分两步,先跟进 mappedHandler = getHandler(processedRequest);方法
看看他干啥了,遍历所有的HandlerMapping
第一个问题: 还记不记得哪里来的RequestMappingHandlerMapping,没错就是文章一开始我们去看初始化DispatcherServlet时在静态块里面完成的加载已经后续的初始化,所以按理说,下面的数组中就存在两个handlerMapping分别是BeanNameUrlHandlerMapping和RequestMappingHandlerMapping
第二个问题: 什么是HandlerMapping? 直接看它的中文翻译就是处理器映射器是不好理解的,其实也没有特别难懂, 就是一个映射器嘛,映射什么呢? 就是映射用户的请求与后端程序员编写的Controller之间的关系, 再直白一点, 就是一个用户的请求经过了这个HandlerMapping就可以百分百确定出哪一个控制器是用来处理它的
第三个问题: 下面的HandlerMapping是个数组,意味着这个映射的规则是多种多样的,所以来个循环,如果没有任何一个映射器满足条件怎么办呢? 404呗
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
for (HandlerMapping hm : this.handlerMappings) {
if (logger.isTraceEnabled()) {
logger.trace(
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "'");
}
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
于是经过了上面HandlerMapping的处理我们获取出来了一个 HandlerExecutionChain ,并且我们百分百确定这个 HandlerExecutionChain 就是用来处理当前的请求的,但是!!! 我们却不能直接使用,因为我们是不清楚前面的获取到的这个执行器链是个方法,还是个类,于是适配器就用上了
源码如下:
这个适配器就是HandlerAdapter,使用设配器设计模式,不管得到的handler到底是什么类型的,都可以找到正确的方法区执行它
HandlerAdapter同样是DisapcherServlet的一大组件,它和上面的处理器映射器是一样的,同样是从配置文件中被读取出来
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
if (this.handlerAdapters != null) {
for (HandlerAdapter ha : this.handlerAdapters) {
if (logger.isTraceEnabled()) {
logger.trace("Testing handler adapter [" + ha + "]");
}
if (ha.supports(handler)) {
return ha;
}
}
}
throw new ServletException("No adapter for handler [" + handler +
"]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}
咋样? 其实本文倒是也没什么难度,就是觉得确实挺好玩的...
