博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SpringMVC源码学习(二) - DispatcherServlet和相关组件
阅读量:4211 次
发布时间:2019-05-26

本文共 2382 字,大约阅读时间需要 7 分钟。

在上期分析中,大概了解了DispatcherServlet的几个组件,这期我们就主要看看后边的几个组件。主要是错误处理转化器、静态资源解析器、视图解析器和flash处理器等。

我们知道如果我们的程序出现了错误,最后报错的是tomcat的线程,在他的前面就是我们servlet了,那么在Servlet这里如何处理这些异常?如果不处理必然导致tomcat线程的崩溃。我个人觉得这里的异常处理器应该就是代码异常的最后处理了。是这样吗?

看到springMvc首先获取所有的HandlerExceptionResolver处理器解析器。然后进行排序什么的一系列处理,最终成为一个列表。

public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {    //判断是否能被识别    if (!this.shouldApplyTo(request, handler)) {        return null;    } else {        //对response进行处理        this.prepareResponse(ex, response);        //对异常进行处理        ModelAndView result = this.doResolveException(request, response, handler, ex);        if (result != null) {            if (this.logger.isDebugEnabled() && (this.warnLogger == null || !this.warnLogger.isWarnEnabled())) {                this.logger.debug("Resolved [" + ex + "]" + (result.isEmpty() ? "" : " to " + result));                }                //日志            this.logException(ex, request);            }        return result;    }}protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) {    //handler,可认为是controller等    if (handler != null) {    //看会否包含        if (this.mappedHandlers != null && this.mappedHandlers.contains(handler)) {            return true;        }        if (this.mappedHandlerClasses != null) {            Class[] var3 = this.mappedHandlerClasses;            int var4 = var3.length;            for(int var5 = 0; var5 < var4; ++var5) {                Class
handlerClass = var3[var5]; if (handlerClass.isInstance(handler)) { return true; } } }    } return this.mappedHandlers == null && this.mappedHandlerClasses == null;}

在这里我们发现默认设置的异常处理的没有浏览器缓存的。

当然这里的异常处理器有很多,看样子是对不同的异常有不同的报错提示。那么它是如何兼容或者找到合适的异常处理器的?觉得这个和SpringApplication中决定是否要有Servlet容器一般应该在调用的时候决定。在后期调用链学习中再看这样的想法是否正确。现在先这样考虑吧。

在initRequestToViewNameTranslator方法中,我们发现这里有前缀和后缀。所以这个RequestToViewNameTranslator应该是传入请求返回一个视图的模块。当然这块应该也是在请求的返回的时候调用。但是通过查看实现类,发现实现类只有一个。

initViewResolvers方法用来初始化视图解析器。

这块也是先从IOC中获取,获取不到到的话采用默认的视图解析器。之前在工作中看到10年的架构师自己写视图解析器的,主要是对返回的的数据比如json或者字符串甚至图片进行处理然后write到outputstream流中。

查看默认实例,发现这块采用的是jsp的视图解析器。

在fashMapManager的初始化也是先从IOC中获取,获取不到则采用默认策略。但是这个FlashMapManager究竟是什么?通过查询网络博客,发现这个是用于防重复提交的。这块后期有机会再专门写一篇吧。我也是在一边学习一边输出,很多说法可能有问题。希望大家多多包含。谢谢大家!

转载地址:http://ihkmi.baihongyu.com/

你可能感兴趣的文章
GPIO的上拉电阻的作用
查看>>
kernel power off流程分析
查看>>
Qualcomm pmic充电流程分析(msm8660)
查看>>
web开发了解
查看>>
android switch模块
查看>>
linux内核中container_of
查看>>
USB History Viewing
查看>>
Android 关机流程分析-案例高通平台
查看>>
android restart reason机制
查看>>
linux cpufeq相关知识
查看>>
cpufreq变频子系统
查看>>
怎样做可靠的分布式锁,Redlock 真的可行么?
查看>>
[图文] Seata AT 模式分布式事务源码分析
查看>>
__asm__ __volatile__("":::"memory"),内存屏障(memory barrier)
查看>>
添加系统调用的方法,2.6.35(没有测试)
查看>>
v4l2
查看>>
wubi的错
查看>>
Saving Data in SQL Databases
查看>>
textFields
查看>>
pm 源码分析
查看>>