代码分析Spring MVC的工作原理

遗留问题

在关于利用maven搭建ssm的博客,我们一起来探讨下问的最多的问题中,我遗留了一个问题:Spring mvc是何时、何地、如何将Model中的属性绑定到哪个作用域,这里的作用域指的是Servlet的四大作用域;不了解问题背景的可以回过头去看看我的上篇博文。

明确的解答我会放到最后,在解答问题之前,我先和大家一起来捋一捋Spring mvc的工作原理。废话不多说,开始我们神秘的探险之旅!

应用示例

在讲工作原理之前,我们先看一个简单的spring mvc(ssm)示例,以及实现的效果

工程代码地址:ssm-web 

工程结构与效果如上所示,我们不做过多的探究,我们打起精神往下看本篇的重点

工作原理

准备 - 资源的加载与初始化

1、DispatcherServlet 静态初始化

DispatcherServlet中有如下静态块

static {
 // Load default strategy implementations from properties file.
 // This is currently strictly internal and not meant to be customized
 // by application developers.
 try {
  ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
  defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
 }
 catch (IOException ex) {
  throw new IllegalStateException("Could not load 'DispatcherServlet.properties': " + ex.getMessage());
 }
 }

这里会将DispatcherServlet.properties中的内容读取到DispatcherServlet的属性:private static final Properties defaultStrategies中,DispatcherServlet.properties内容如下

# 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.

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.annotation.DefaultAnnotationHandlerMapping

org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
 org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
 org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter

org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver,\
 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策略接口的默认实现,后续DispatcherServlet初始化策略的时候会用到

2、interceptor定义的加载

spring启动过程中会调用InterceptorsBeanDefinitionParser的parse方法来解析出我们自定义的interceptor定义,封装成MappedInterceptor类型的bean定义,并放到spring容器中;我们可以简单的认为spring容器中已经存在了我们自定义的interceptor的bean定义

3、DispatcherServlet初始化策略:initStrategies

DispatcherServlet的继承图如下

DispatcherServlet是一个Servlet,tomcat启动过程中会调用其init方法,一串的调用后,会调用DispatcherServlet的initStrategies方法

protected void initStrategies(ApplicationContext context) {
 initMultipartResolver(context);
 initLocaleResolver(context);
 initThemeResolver(context);
 initHandlerMappings(context);
 initHandlerAdapters(context);
 initHandlerExceptionResolvers(context);
 initRequestToViewNameTranslator(context);
 initViewResolvers(context);
 initFlashMapManager(context);
}

实例化步骤1中的默认实现,并填充到DispatcherServlet各个属性值中

4、DefaultAnnotationHandlerMapping的拦截器初始化

DispatcherServlet.properties种指定了两个默认的HandlerMapping:BeanNameUrlHandlerMapping、DefaultAnnotationHandlerMapping,这两者的类继承图如下(我们暂时只关注DefaultAnnotationHandlerMapping)

DefaultAnnotationHandlerMapping间接实现了ApplicationContextAware,那么在DefaultAnnotationHandlerMapping实例初始化过程中,会调用setApplicationContext(ApplicationContext applicationContext)方法,一串调用后,会来到AbstractUrlHandlerMapping的initApplicationContext()

@Override
protected void initApplicationContext() throws BeansException {
 extendInterceptors(this.interceptors);
 detectMappedInterceptors(this.mappedInterceptors);
 initInterceptors();
}

初始化了DefaultAnnotationHandlerMapping的拦截器:interceptor

我们来看下具体的初始化过程,看看上面的顺序是否只是我个人的臆想?

可以看到,初始化顺序就是我们上面说的,不是我个人的意淫;此时的DefaultAnnotationHandlerMapping中有我们自定义的MyInterceptor。初始化过程我们需要关注的就是上述这些,下面我们一起看看具体请求的过程

请求的处理

请求从servlet的service开始,一路到DispatcherServlet的doDispatch,如下图

doDispatch

/**
 * Process the actual dispatching to the handler. 将请求分发到具体的handler,也就是我们的controller
 * <p>The handler will be obtained by applying the servlet's HandlerMappings in order.
 * The HandlerAdapter will be obtained by querying the servlet's installed HandlerAdapters
 * to find the first that supports the handler class.
 * <p>All HTTP methods are handled by this method. It's up to HandlerAdapters or handlers
 * themselves to decide which methods are acceptable.
 * @param request current HTTP request
 * @param response current HTTP response
 * @throws Exception in case of any kind of processing failure
 */
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. 决定哪个handler来处理当前的请求
   // mappedHandler是由handler和interceptor集合组成的一个执行链,有点类似FilterChain
   mappedHandler = getHandler(processedRequest);
   if (mappedHandler == null || mappedHandler.getHandler() == null) {
    noHandlerFound(processedRequest, response);
    return;
   }

   // Determine handler adapter for the current request. 决定哪个adapter来处理当前的请求
   // handlerMapping是找出适配的handler,而真正回调handler的是adapter
   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()) {
     String requestUri = urlPathHelper.getRequestUri(request);
     logger.debug("Last-Modified value for [" + requestUri + "] is: " + lastModified);
    }
    if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
     return;
    }
   }

   // handler的前置处理,也就是调用适配当前url的interceptor的preHandler方法
   if (!mappedHandler.applyPreHandle(processedRequest, response)) {
    return;
   }

   try {
    // Actually invoke the handler. 真正调用handler
    mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
   }
   finally {
    if (asyncManager.isConcurrentHandlingStarted()) {
     return;
    }
   }

   applyDefaultViewName(request, mv);
   // handler的后置处理,也就是调用适配当前url的interceptor的postHandler方法
   mappedHandler.applyPostHandle(processedRequest, response, mv);
  }
  catch (Exception ex) {
   dispatchException = ex;
  }
  // 处理handler返回的结果,会调用适配当前url的interceptor的afterCompletion方法
  // 这里会将响应结果返回给请求者
  processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
 }
 catch (Exception ex) {
  triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
 }
 catch (Error err) {
  triggerAfterCompletionWithError(processedRequest, response, mappedHandler, err);
 }
 finally {
  if (asyncManager.isConcurrentHandlingStarted()) {
   // Instead of postHandle and afterCompletion
   mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
   return;
  }
  // Clean up any resources used by a multipart request.
  if (multipartRequestParsed) {
   cleanupMultipart(processedRequest);
  }
 }
}

handlerMapping具体如何找到匹配当前url的handler(一般而言就是我们的controller)、handlerAdapter具体如何回调真正的handler,有兴趣的可以自行去跟下,我就不跟了。我们具体看下processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException); 这个与我们最初的疑问有关

processDispatchResult

可以看到model中的persons会被设置到request的attributes中,然后转发请求到show_person.jsp,转发过程中request作用域的变量仍然有效,所以show_person.jsp中的jstl标签和el表达式能够取到persons变量,最后将show_person.jsp中的内容填充好之后的静态内容返回给请求者;至此就完成了一次请求的响应

问题解答

回到我们开篇的疑问:Spring mvc是何时、何地、如何将Model中的属性绑定到哪个作用域?想必大家已经知道答案了

Controller中的model、ModelMap的注入由spring mvc完成,这个不是请求传入的参数,用于绑定变量到Servlet作用域;默认情况下,在DispatcherServlet调用了真正的handler之后,将结果返回给请求者的过程中,将model、modelMap中的变量设置到了request的attributes中,转发的过程中,request中的变量仍然有效,所以show_person.jsp中能取到persons这个变量,自此疑问得到解答

总结

1、Spring MVC工作原理图

图是用的别人的,具体是谁的我也不记得了(捂脸)

2、DefaultAnnotationHandlerMapping在spring3.2中被废弃,替换成了RequestMappingHandlerMapping

(0)

相关推荐

  • Spring mvc工作原理_动力节点Java学院整理

    SpringMVC框架介绍 Spring MVC属于SpringFrameWork的后续产品,已经融合在Spring Web Flow里面. Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块.使用 Spring 可插入的 MVC 架构,可以选择是使用内置的 Spring Web 框架还是 Struts 这样的 Web 框架.通过策略接口,Spring 框架是高度可配置的,而且包含多种视图技术,例如 JavaServer Pages(JSP)技术.Velocity.Tiles

  • 代码分析Spring MVC的工作原理

    遗留问题 在关于利用maven搭建ssm的博客,我们一起来探讨下问的最多的问题中,我遗留了一个问题:Spring mvc是何时.何地.如何将Model中的属性绑定到哪个作用域,这里的作用域指的是Servlet的四大作用域:不了解问题背景的可以回过头去看看我的上篇博文. 明确的解答我会放到最后,在解答问题之前,我先和大家一起来捋一捋Spring mvc的工作原理.废话不多说,开始我们神秘的探险之旅! 应用示例 在讲工作原理之前,我们先看一个简单的spring mvc(ssm)示例,以及实现的效果

  • 通过代码实例解析PHP session工作原理

    这里的介绍主要是基于php语言,其他的语言操作可能会有差别,但基本的原理不变. 1.在php中如何操作session: session_start(); //使用该函数打开session功能 $_SESSION //使用预定义全局变量操作数据 使用unset($_SESSION['key']) //销毁一个session的值 简单地操作,一切都是由服务器实现:由于处理在后台,一切看起来也很安全.但是session采用什么样机制,又是怎样被实现,并且如何来保持会话的状态的呢? 2.session实

  • spring mvc DispatcherServlet之前端控制器架构详解

    前端控制器是整个MVC框架中最为核心的一块,它主要用来拦截符合要求的外部请求,并把请求分发到不同的控制器去处理,根据控制器处理后的结果,生成相应的响应发送到客户端.前端控制器既可以使用Filter实现(Struts2采用这种方式),也可以使用Servlet来实现(spring MVC框架). DispatcherServlet 作为前置控制器是web服务器的入口,是spring mvc最重要的一个类,通过它的生命周期可以加深对web服务器的理解. servlet的生命周期 首先我们回忆一下ser

  • springboot中@Value的工作原理说明

    我们知道springboot中的Bean组件的成员变量(属性)如果加上了@Value注解,可以从有效的配置属性资源中找到配置项进行绑定,那么这一切是怎么发生的呢? 下文将简要分析一下@Value的工作原理. springboot版本: springboot-2.0.6.RELEASE 概述 springboot启动过程中,有两个比较重要的过程,如下: 1 扫描,解析容器中的bean注册到beanFactory上去,就像是信息登记一样. 2 实例化.初始化这些扫描到的bean. @Value的解析

  • 详解使用Spring MVC统一异常处理实战

    1 描述 在J2EE项目的开发中,不管是对底层的数据库操作过程,还是业务层的处理过程,还是控制层的处理过程,都不可避免会遇到各种可预知的.不可预知的异常需要处理.每个过程都单独处理异常,系统的代码耦合度高,工作量大且不好统一,维护的工作量也很大. 那么,能不能将所有类型的异常处理从各处理过程解耦出来,这样既保证了相关处理过程的功能较单一,也实现了异常信息的统一处理和维护?答案是肯定的.下面将介绍使用Spring MVC统一处理异常的解决和实现过程. 2 分析 Spring MVC处理异常有3种方

  • Spring MVC学习之DispatcherServlet请求处理详析

    前言 要深入理解spring mvc的工作流程,就需要先了解spring mvc的架构: 从上图可以看到 前端控制器DispatcherServlet在其中起着主导作用,理解了DispatcherServlet 就完全可以说弄清楚了spring mvc. DispatcherServlet作为Spring用于处理web请求注册的唯一一个Servlet,所有的请求都是经由DispatcherServlet进行分发处理的.本文主要讲解DispatcherServlet是如何对请求进行分发,处理,并且

  • 从源码角度看spring mvc的请求处理过程

    在分析spring mvc源码之前,先看一张图: 请求处理的过程: 1.DispatcherServelt作为前端控制器,拦截request对象. 2.DispatcherServlet接收到request对象之后,查询HandlerMapping,得到一个HandlerExecutionChain对象. 3.DispatcherServlet将Handler对象交由HandlerAdapter(适配器模式的典型应用),调用相应的controller方法. 4.Controller方法返回Mod

  • Spring MVC 前端控制器 (DispatcherServlet)处理流程解析

    目录 Spring MVC 请求处理流程 DispatcherServlet 源码分析 Spring MVC 中的一些核心类 Spring MVC 请求处理流程 用户发起请求,到 DispatcherServlet; 然后到 HandlerMapping 返回处理器链(包含拦截器和具体处理的 Handler); 调用处理器链的适配器 HandlerAdapter 来处理: 执行具体的方法,比如 @RequestMapper修饰的逻辑处理方法: 返回结果的视图解析器: 最后进行视图解析和渲染返回结

  • Spring MVC策略模式之MethodArgumentResolver源码解析

    目录 正文 例子 源码分析 RequestParamMethodArgumentResolver: PathVariableMethodArgumentResolver: ModelMethodProcessor: 总结 正文 Spring MVC 是一个基于 MVC 设计模式的Web框架,它的核心就是 DispatcherServlet,它相当于请求的中央处理器.在 DispatcherServlet 中,它使用了 MethodArgumentResolver 来解析方法参数. MethodA

随机推荐