【小家Spring】Spring MVC执行流程 FrameworkServlet、DispatcherServlet源码分析(processRequest、doDispatch)(下)

简介: 【小家Spring】Spring MVC执行流程 FrameworkServlet、DispatcherServlet源码分析(processRequest、doDispatch)(下)


SpringMVC默认加载三个请求处理映射类:RequestMappingHandlerMapping、SimpleUrlHandlerMapping、和BeanNameUrlHandlerMapping。

这三个类有一个共同的父类:AbstractHandlerMapping。在上面代码中hm.getHandler(request)这个getHandler方法在AbstractHandlerMapping中,它的子类都没有重写这个方法。因此我们含有必要去AbstractHandlerMapping这个类中看一下这个方法:


  @Override
  @Nullable
  public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    // 这个是留给子类去重写实现的:查找handler处理器的~ 比如根据URL去查找匹配等等
    // 备注:获取hadnler的过程,非常的复杂,这个必须后面单独的专题再说吧
    Object handler = getHandlerInternal(request);
    if (handler == null) {
      handler = getDefaultHandler();
    }
    if (handler == null) {
      return null;
    }
    // Bean name or resolved handler?
    if (handler instanceof String) {
      String handlerName = (String) handler;
      handler = obtainApplicationContext().getBean(handlerName);
    }
    //构建出一个处理器链   注意:和handler绑定了,并且内部还去拿到了所有的拦截器,然后添加到处理器连里面去   getHandlerExecutionChain() 方法自己去看,可以看明白
    HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
    //是不是cors请求,cors是跨域请求
    if (CorsUtils.isCorsRequest(request)) {
      CorsConfiguration globalConfig = this.globalCorsConfigSource.getCorsConfiguration(request);
      CorsConfiguration handlerConfig = getCorsConfiguration(handler, request);
      CorsConfiguration config = (globalConfig != null ? globalConfig.combine(handlerConfig) : handlerConfig);
      executionChain = getCorsHandlerExecutionChain(request, executionChain, config);
    }
    return executionChain;
  }


HandlerExecutionChain#applyPreHandle


  boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {
    HandlerInterceptor[] interceptors = getInterceptors();
    if (!ObjectUtils.isEmpty(interceptors)) {
      for (int i = 0; i < interceptors.length; i++) {
        HandlerInterceptor interceptor = interceptors[i];
        // 注意:如果是拦截器返回了false,就立马触发所有拦截器的AfterCompletion 方法。并且马上return false
        if (!interceptor.preHandle(request, response, this.handler)) {
          triggerAfterCompletion(request, response, null);
          return false;
        }
        this.interceptorIndex = i;
      }
    }
    return true;
  }


processDispatchResult


  private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
      @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
      @Nullable Exception exception) throws Exception {
    boolean errorView = false;
    //如果有异常,就进入异常处理逻辑,返回到异常页面
    if (exception != null) {
      // 含有异常页面视图的异常
      if (exception instanceof ModelAndViewDefiningException) {
        logger.debug("ModelAndViewDefiningException encountered", exception);
        mv = ((ModelAndViewDefiningException) exception).getModelAndView();
      } else {
        Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
        //1、会执行所有的我们的自己配置(或者默认配置)了的HandlerExceptionResolver处理器 
        //2、上面需要注意了,但凡处理方法返回的不是null,有mv的返回。那后面的处理器就不会再进行处理了。具有短路的效果,一定要注意  是通过null来判断的
        //3、处理完成后,得到error的视图mv,最后会设置一个viewName,然后返回出去
        mv = processHandlerException(request, response, handler, exception);
        errorView = (mv != null);
      }
    }
    // 若视图不为空,不为null,就开始执行render()方法,开始渲染视图了
    if (mv != null && !mv.wasCleared()) {
      render(mv, request, response);
      // 如果有错误视图,这里清除掉所有的请求域里的所有的错误属性
      if (errorView) {
        WebUtils.clearErrorRequestAttributes(request);
      }
    }
    //处理异步=========我们发现,它不执行后面的AfterCompletion方法了,注意一下即可
    if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
      // Concurrent handling started during a forward
      return;
    }
    // 执行拦截器的AfterCompletion 方法
    if (mappedHandler != null) {
      mappedHandler.triggerAfterCompletion(request, response, null);
    }
  }


至此,只剩一个视图渲染的方法:render()


  protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
    // 通过localeResolver吧local解析出来,放到response里面去
    Locale locale = (this.localeResolver != null ? this.localeResolver.resolveLocale(request) : request.getLocale());
    response.setLocale(locale);
    //==================视图:关键中的关键==================
    View view;
    String viewName = mv.getViewName();
    // 如果已经有viewName了(绝大多数情况)
    if (viewName != null) {
      // 视图解析器  根据String类型的名字,解析出来一个视图(视图解析器有多个)
      // 还是那个原理:只要有一个返回了不为null的,后面的就不会再解析了
      view = resolveViewName(viewName, mv.getModelInternal(), locale, request);
      // 如果解析不出来视图,那就抛出异常,说不能解析该视图
      if (view == null) {
        throw new ServletException("Could not resolve view with name '" + mv.getViewName() +
            "' in servlet with name '" + getServletName() + "'");
      }
    } else { //没有视图名称,但是必须有视图内容,否则抛出异常
      view = mv.getView();
      if (view == null) {
        throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " +
            "View object in servlet with name '" + getServletName() + "'");
      }
    }
    try {
      //设置响应马 status
      if (mv.getStatus() != null) {
        response.setStatus(mv.getStatus().value());
      }
      // 根据model里的数据,正式渲染(关于此部分逻辑,后续再说,也比较复杂)
      view.render(mv.getModelInternal(), request, response);
    } catch (Exception ex) {
      throw ex;
    }
  }


至此,整个Spring MVC处理请求的一个过程算是结束了


总结


本文从FrameworkServlet、DispatcherServlet源码处去跟踪比较具象的去描述了Spring MVC的一个执行过程。从中我们可以深刻感受到,Spring在考虑这些问题的时候还是非常全面的。

还能感受它里面使用得丝滑般的设计模式:门面模式、模版模式等等~~


Spring MVC作为现在Java Web开发中实际的规范,大多数时候我们只需要着眼关注我们自己书写的Controller本身了,但是如果我们想做一些优雅处理:全局异常处理、数据绑定处理、序列化反序列化定制化处理等等,理解这些工作流程,现在就如有神助了


相关文章
|
监控 Java 应用服务中间件
Spring Boot整合Tomcat底层源码分析
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置和起步依赖等特性,大大简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是其与Tomcat的整合。
317 1
|
10月前
|
监控 Java 应用服务中间件
SpringBoot是如何简化Spring开发的,以及SpringBoot的特性以及源码分析
Spring Boot 通过简化配置、自动配置和嵌入式服务器等特性,大大简化了 Spring 应用的开发过程。它通过提供一系列 `starter` 依赖和开箱即用的默认配置,使开发者能够更专注于业务逻辑而非繁琐的配置。Spring Boot 的自动配置机制和强大的 Actuator 功能进一步提升了开发效率和应用的可维护性。通过对其源码的分析,可以更深入地理解其内部工作机制,从而更好地利用其特性进行开发。
408 6
|
11月前
|
设计模式 XML Java
【23种设计模式·全精解析 | 自定义Spring框架篇】Spring核心源码分析+自定义Spring的IOC功能,依赖注入功能
本文详细介绍了Spring框架的核心功能,并通过手写自定义Spring框架的方式,深入理解了Spring的IOC(控制反转)和DI(依赖注入)功能,并且学会实际运用设计模式到真实开发中。
【23种设计模式·全精解析 | 自定义Spring框架篇】Spring核心源码分析+自定义Spring的IOC功能,依赖注入功能
|
缓存 JavaScript Java
Spring之FactoryBean的处理底层源码分析
本文介绍了Spring框架中FactoryBean的重要作用及其使用方法。通过一个简单的示例展示了如何通过FactoryBean返回一个User对象,并解释了在调用`getBean()`方法时,传入名称前添加`&`符号会改变返回对象类型的原因。进一步深入源码分析,详细说明了`getBean()`方法内部对FactoryBean的处理逻辑,解释了为何添加`&`符号会导致不同的行为。最后,通过具体代码片段展示了这一过程的关键步骤。
157 1
Spring之FactoryBean的处理底层源码分析
|
前端开发 Java Spring
Spring MVC源码分析之DispatcherServlet#getHandlerAdapter方法
`DispatcherServlet`的 `getHandlerAdapter`方法是Spring MVC处理请求的核心部分之一。它通过遍历预定义的 `HandlerAdapter`列表,找到适用于当前处理器的适配器,并调用适配器执行具体的处理逻辑。理解这个方法有助于深入了解Spring MVC的工作机制和扩展点。
140 1
|
前端开发 Java Spring
Spring MVC源码分析之DispatcherServlet#getHandlerAdapter方法
`DispatcherServlet`的 `getHandlerAdapter`方法是Spring MVC处理请求的核心部分之一。它通过遍历预定义的 `HandlerAdapter`列表,找到适用于当前处理器的适配器,并调用适配器执行具体的处理逻辑。理解这个方法有助于深入了解Spring MVC的工作机制和扩展点。
143 1
|
前端开发 Java Spring
Spring MVC源码分析之DispatcherServlet#getHandlerAdapter方法
`DispatcherServlet`的 `getHandlerAdapter`方法是Spring MVC处理请求的核心部分之一。它通过遍历预定义的 `HandlerAdapter`列表,找到适用于当前处理器的适配器,并调用适配器执行具体的处理逻辑。理解这个方法有助于深入了解Spring MVC的工作机制和扩展点。
115 0
|
开发框架 前端开发 .NET
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
435 0
|
存储 开发框架 前端开发
[回馈]ASP.NET Core MVC开发实战之商城系统(五)
经过一段时间的准备,新的一期【ASP.NET Core MVC开发实战之商城系统】已经开始,在之前的文章中,讲解了商城系统的整体功能设计,页面布局设计,环境搭建,系统配置,及首页【商品类型,banner条,友情链接,降价促销,新品爆款】,商品列表页面,商品详情等功能的开发,今天继续讲解购物车功能开发,仅供学习分享使用,如有不足之处,还请指正。
325 0
|
开发框架 前端开发 .NET
[回馈]ASP.NET Core MVC开发实战之商城系统(三)
[回馈]ASP.NET Core MVC开发实战之商城系统(三)
253 0