springboot如何让404错误统一走自定义异常处理流程
最近在springboot开发的一个项目中,发现了一个奇怪的问题。
发现随便访问一个不存在的接口,总是能找到一个对应的hander,并没有进入预期中的404处理流程。
为了解决统一异常处理的问题,仔细梳理了一次spring mvc的 DispatcherServlet 的处理流程。让我觉得好奇和感兴趣的是,在debug的过程中,spring boot在默认情况下,为我们准备了7个HandlerMapping,而单独使用springmvc XML配置注解驱动下的spring mvc提供的默认HandlerMapping只有三个。
XML配置中的注解驱动
熟悉spring容器的初始化流程的同学们可能知道,spring 容器在解析XML配置文件的阶段会处理自定义的名字空间,例如 mvc: ,mvc这个名字空间就是在该阶段处理。
在该阶段,spring读取每个包 META-INF 下的 spring.schemas 和 spring.handlers 文件,这些文件映射了名字空间和处理该名字空间的处理器。spring实例化这些处理器,并找到处理对应名字空间的处理器,运行init方法。
现在回到本文的配角:mvc。 该名字空间的处理器是 MvcNamespaceHandler 。MvcNamespaceHandler 的 init方法中,向spring 容器中注册了各种各样的 BeanDefinitionParser实例,这些实例将解析各自的mvc名字空间下的元素。其中,注解驱动 mvc:annotation-driven 节点的annotation-driven 元素由 AnnotationDrivenBeanDefinitionParser 解析器解析 。
AnnotationDrivenBeanDefinitionParser 解析器在解析 annotation-driven 元素时被调用。在解析阶段,会向spring容器中注册一些默认的bean。例如大家熟悉的HandlerMapping 、HandlerAdapter等。在这里,将会向spring 容器注册这些bean的beanDefinition,容器在接下来的流程中会实例化bean并注册到容器中。下面是默认的3个handlerMapping。
spring boot下的handlerMapping
spring boot为了减少开发者的配置工作量,提供了各种各样的自动配置类,官方的自动配置类都在spring-boot-autoconfigure 包下。
spring boot是在什么时候、怎么做到自动配置的呢?
我们注意到 EnableAutoConfiguration 注解上有个@Import注解,该注解相当于XML配置中的 引入其它配置文件。
@Import注解中指定了 选择器 AutoConfigurationImportSelector ,该选择器的作用是在 selectImports() 方法中从spring.factories 文件中获取 key 为 org.springframework.boot.autoconfigure.EnableAutoConfiguration 指定的所有类。然后把这些类都加入到了容器中。
另外,这些类有个共同特点:它们都有个 @Configuration 注解。Spring中对Configuration类的解析是通过 ConfigurationClassPostProcessor 进行的。具体的过程大家可以自行查看代码。总之,@Configuration 注解标识的类中所有的@Bean的类又这样实例化并放到了容器中。
我们花了一些篇幅介绍 EnableAutoConfiguration 的原理,那么有什么用呢?
回到 spring.factories 文件中,我们在 org.springframework.boot.autoconfigure.EnableAutoConfiguration 中发现了关键类:WebMvcAutoConfiguration 。
说到这里,我们看下spring boot启动下,默认情况下,DispatcherServlet中的HandlerMapping有哪些。通过debug,可以看到spring boot默认给我们准备了7个HandlerMapping。
下面简单说明下前5个HandlerMapping的作用和匹配的URL。
(1)第一个SimpleUrlHandlerMapping
该bean在 WebMvcAutoConfiguration 的内部配置类 FaviconConfiguration 中声明。它匹配的URL路径是**/favicon.ico,作用是响应浏览器获取收藏夹中的icon文件。
(2)RequestMappingHandlerMapping
该bean在 WebMvcAutoConfiguration 的内部配置类 EnableWebMvcConfiguration 中声明。它和XML的注解驱动一样,匹配在Controller中@RequestMapping注解指定的URL。
(3)WelcomePageHandlerMapping
该bean在 WebMvcAutoConfiguration 的内部配置类 WebMvcAutoConfigurationAdapter 中声明。给URL路径是/或者/index映射到欢迎页面。
(4)BeanNameUrlHandlerMapping
bean的名称(也就是beanID)作为URL,由匹配该URL的Controller处理业务。Controller必须继承AbstractController。基本不会在工作中使用这个玩意。
(5)第二个SimpleUrlHandlerMapping
该bean在WebMvcAutoConfiguration 的内部配置类 EnableWebMvcConfiguration 的父类 WebMvcConfigurationSupport 中声明。
@Bean
public HandlerMapping resourceHandlerMapping() {}
从该bean的名称,可以知道它是专门用于映射资源文件的handlerMapping。看下它的URL与handler的映射关系
可以看到,其中有一个/**,所有匹配不到的接口请求将由ResourceHttpRequestHandler处理、获取并返回。而ResourceHttpRequestHandler内部将会查找对应的静态资源,如果查不到将直接response.sendError()最终重定向到/error视图,最终交给springboot默认的/error控制器处理。
默认的/error控制器对应rest请求会返回一个json格式的数据,而普通的请求会基于HTTP错误状态码去error/下查找对应状态码的视图。
如何让404请求统一走自定义异常处理流程
通过上述分析,可以知道,对于默认的springboot配置,不存在的接口会走入/error流程,最根本的原因是配置了处理/**的
@Bean
public HandlerMapping resourceHandlerMapping() {}
基于此,我们首先先去除这个配置。
在org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter#addResourceHandlers中加入了/**的配置。
我们通过在spring的配置文件中加入
spring.resources.addMappings=false
表示不加入默认的静态资源路径处理。
这样再次访问一个不存在的接口,我们会看到DispatchServlet中会返回null了,进入noHandlerFound()。
默认配置下,找不到hander,直接sendError()。我们期望让它抛出异常,已便在后面的异常处理器中处理。
在spring的配置文件中加入
spring.mvc.throw-exception-if-no-handler-found=true
让其抛出异常,这样我们就能处理这个异常了。
小结
springboot确实简单方便,你完全不需要任何配置就能让springmvc运转起来。但也正是因为简单而让你失去了内部的细节,因此你在使用前强烈建议必须要十分清楚底层的原理,否则可能会发生很多超乎你预期的结果。