Spring Boot配置接口WebMvcConfigurer的实现

WebMvcConfigurer配置类其实是Spring内部的一种配置方式,采用JavaBean的形式来代替传统的xml配置文件形式进行针对框架个性化定制。基于java-based方式的spring mvc配置,需要创建一个配置类并实现WebMvcConfigurer 接口,WebMvcConfigurerAdapter 抽象类是对WebMvcConfigurer接口的简单抽象(增加了一些默认实现),但在在SpringBoot2.0及Spring5.0中WebMvcConfigurerAdapter已被废弃 。官方推荐直接实现WebMvcConfigurer或者直接继承WebMvcConfigurationSupport,方式一实现WebMvcConfigurer接口(推荐),方式二继承WebMvcConfigurationSupport类,具体实现可看这篇文章。https://www.jb51.net/article/174766.htm

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package org.springframework.web.servlet.config.annotation;

import java.util.List;
import org.springframework.format.FormatterRegistry;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.validation.MessageCodesResolver;
import org.springframework.validation.Validator;
import org.springframework.web.method.support.HandlerMethodArgumentResolver;
import org.springframework.web.method.support.HandlerMethodReturnValueHandler;
import org.springframework.web.servlet.HandlerExceptionResolver;

public interface WebMvcConfigurer {
 void configurePathMatch(PathMatchConfigurer var1);

 void configureContentNegotiation(ContentNegotiationConfigurer var1);

 void configureAsyncSupport(AsyncSupportConfigurer var1);

 void configureDefaultServletHandling(DefaultServletHandlerConfigurer var1);

 void addFormatters(FormatterRegistry var1);

 void addInterceptors(InterceptorRegistry var1);

 void addResourceHandlers(ResourceHandlerRegistry var1);

 void addCorsMappings(CorsRegistry var1);

 void addViewControllers(ViewControllerRegistry var1);

 void configureViewResolvers(ViewResolverRegistry var1);

 void addArgumentResolvers(List<HandlerMethodArgumentResolver> var1);

 void addReturnValueHandlers(List<HandlerMethodReturnValueHandler> var1);

 void configureMessageConverters(List<HttpMessageConverter<?>> var1);

 void extendMessageConverters(List<HttpMessageConverter<?>> var1);

 void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> var1);

 void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> var1);

 Validator getValidator();

 MessageCodesResolver getMessageCodesResolver();
}

接下来我们着重找几个方法讲解一下:

 /* 拦截器配置 */
void addInterceptors(InterceptorRegistry var1);
/* 视图跳转控制器 */
void addViewControllers(ViewControllerRegistry registry);
/**
  *静态资源处理
**/
void addResourceHandlers(ResourceHandlerRegistry registry);
/* 默认静态资源处理器 */
void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer);
/**
  * 这里配置视图解析器
 **/
void configureViewResolvers(ViewResolverRegistry registry);
/* 配置内容裁决的一些选项*/
void configureContentNegotiation(ContentNegotiationConfigurer configurer);

1、addInterceptors(InterceptorRegistry registry)

此方法用来专门注册一个Interceptor,如HandlerInterceptorAdapter

@Configuration
public class MyWebMvcConfigurer implements WebMvcConfigurer {
@Override
 public void addInterceptors(InterceptorRegistry registry) {
  registry.addInterceptor(new MyInterceptor()).addPathPatterns("/**").excludePathPatterns("/emp/toLogin","/emp/login","/js/**","/css/**","/images/**");
 }
}

addPathPatterns("/**")对所有请求都拦截,但是排除了/toLogin和/login请求的拦截。

当spring boot版本升级为2.x时,访问静态资源就会被HandlerInterceptor拦截,网上有很多处理办法都是如下写法

.excludePathPatterns("/index.html","/","/user/login","/static/**");

可惜本人在使用时一直不起作用,查看请求的路径里并没有/static/如图:

于是我改成了"/js/**","/css/**","/images/**"这样页面内容就可以正常访问了,我的项目结构如下:

2. 页面跳转addViewControllers

以前写SpringMVC的时候,如果需要访问一个页面,必须要写Controller类,然后再写一个方法跳转到页面,感觉好麻烦,其实重写WebMvcConfigurer中的addViewControllers方法即可达到效果了

/**
  * 以前要访问一个页面需要先创建个Controller控制类,再写方法跳转到页面
  * 在这里配置后就不需要那么麻烦了,直接访问http://localhost:8080/toLogin就跳转到login.jsp页面了
  * @param registry
  */
 @Override
 public void addViewControllers(ViewControllerRegistry registry) {
  registry.addViewController("/toLogin").setViewName("login");

 }

值的指出的是,在这里重写addViewControllers方法,并不会覆盖WebMvcAutoConfiguration中的addViewControllers(在此方法中,Spring Boot将“/”映射至index.html),这也就意味着我们自己的配置和Spring Boot的自动配置同时有效,这也是我们推荐添加自己的MVC配置的方式。

3. 自定义资源映射addResourceHandlers

比如,我们想自定义静态资源映射目录的话,只需重写addResourceHandlers方法即可。

注:如果继承WebMvcConfigurationSupport类实现配置时必须要重写该方法,具体见其它文章

@Configuration
public class MyWebMvcConfigurerAdapter implements WebMvcConfigurer {
 /**
  * 配置静态访问资源
  * @param registry
  */
 @Override
 public void addResourceHandlers(ResourceHandlerRegistry registry) {
  registry.addResourceHandler("/my/**").addResourceLocations("classpath:/my/");

 }
}

通过addResourceHandler添加映射路径,然后通过addResourceLocations来指定路径。我们访问自定义my文件夹中的elephant.jpg 图片的地址为 http://localhost:8080/my/elephant.jpg

如果你想指定外部的目录也很简单,直接addResourceLocations指定即可,代码如下:

@Override
 public void addResourceHandlers(ResourceHandlerRegistry registry) {
  registry.addResourceHandler("/my/**").addResourceLocations("file:E:/my/");

 }

addResourceLocations指的是文件放置的目录,addResoureHandler指的是对外暴露的访问路径

4. configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer)

用法:

 @Override
 public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
  configurer.enable();
  configurer.enable("defaultServletName");
 }

此时会注册一个默认的Handler:DefaultServletHttpRequestHandler,这个Handler也是用来处理静态文件的,它会尝试映射/。当DispatcherServelt映射/时(/ 和/ 是有区别的),并且没有找到合适的Handler来处理请求时,就会交给DefaultServletHttpRequestHandler 来处理。注意:这里的静态资源是放置在web根目录下,而非WEB-INF 下。

可能这里的描述有点不好懂(我自己也这么觉得),所以简单举个例子,例如:在webroot目录下有一个图片:1.png 我们知道Servelt规范中web根目录(webroot)下的文件可以直接访问的,但是由于DispatcherServlet配置了映射路径是:/ ,它几乎把所有的请求都拦截了,从而导致1.png 访问不到,这时注册一个DefaultServletHttpRequestHandler 就可以解决这个问题。其实可以理解为DispatcherServlet破坏了Servlet的一个特性(根目录下的文件可以直接访问),DefaultServletHttpRequestHandler是帮助回归这个特性的。

5、configureViewResolvers(ViewResolverRegistry registry)

从方法名称我们就能看出这个方法是用来配置视图解析器的,该方法的参数ViewResolverRegistry 是一个注册器,用来注册你想自定义的视图解析器等。ViewResolverRegistry 常用的几个方法:

1).enableContentNegotiation()

/** 启用内容裁决视图解析器*/
public void enableContentNegotiation(View... defaultViews) {
 initContentNegotiatingViewResolver(defaultViews);
}

该方法会创建一个内容裁决解析器ContentNegotiatingViewResolver ,该解析器不进行具体视图的解析,而是管理你注册的所有视图解析器,所有的视图会先经过它进行解析,然后由它来决定具体使用哪个解析器进行解析。具体的映射规则是根据请求的media types来决定的。

2).  UrlBasedViewResolverRegistration()

 public UrlBasedViewResolverRegistration jsp(String prefix, String suffix) {
  InternalResourceViewResolver resolver = new InternalResourceViewResolver();
  resolver.setPrefix(prefix);
  resolver.setSuffix(suffix);
  this.viewResolvers.add(resolver);
  return new UrlBasedViewResolverRegistration(resolver);
 }

该方法会注册一个内部资源视图解析器InternalResourceViewResolver 显然访问的所有jsp都是它进行解析的。该方法参数用来指定路径的前缀和文件后缀,如:  

registry.jsp("/WEB-INF/jsp/", ".jsp");

对于以上配置,假如返回的视图名称是example,它会返回/WEB-INF/jsp/example.jsp给前端,找不到则报404。  

3).  beanName()

 public void beanName() {
  BeanNameViewResolver resolver = new BeanNameViewResolver();
  this.viewResolvers.add(resolver);
 }

该方法会注册一个BeanNameViewResolver 视图解析器,这个解析器是干嘛的呢?它主要是将视图名称解析成对应的bean。什么意思呢?假如返回的视图名称是example,它会到spring容器中找有没有一个叫example的bean,并且这个bean是View.class类型的?如果有,返回这个bean。  

4).  viewResolver()

 public void viewResolver(ViewResolver viewResolver) {
  if (viewResolver instanceof ContentNegotiatingViewResolver) {
   throw new BeanInitializationException(
     "addViewResolver cannot be used to configure a ContentNegotiatingViewResolver. Please use the method enableContentNegotiation instead.");
  }
  this.viewResolvers.add(viewResolver);
 }

这个方法想必看名字就知道了,它就是用来注册各种各样的视图解析器的,包括自己定义的。

6. configureContentNegotiation(ContentNegotiationConfigurer configurer)

上面我们讲了configureViewResolvers 方法,假如在该方法中我们启用了内容裁决解析器,那么configureContentNegotiation(ContentNegotiationConfigurer configurer) 这个方法是专门用来配置内容裁决的一些参数的。这个比较简单,我们直接通过一个例子看: 

 public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
  /* 是否通过请求Url的扩展名来决定media type */
  configurer.favorPathExtension(true)
     /* 不检查Accept请求头 */
    .ignoreAcceptHeader(true)
    .parameterName("mediaType")
     /* 设置默认的media yype */
    .defaultContentType(MediaType.TEXT_HTML)
     /* 请求以.html结尾的会被当成MediaType.TEXT_HTML*/
    .mediaType("html", MediaType.TEXT_HTML)
    /* 请求以.json结尾的会被当成MediaType.APPLICATION_JSON*/
    .mediaType("json", MediaType.APPLICATION_JSON);
 }

到这里我们就可以举个例子来进一步熟悉下我们上面讲的知识了,假如我们MVC的配置如下:

@EnableWebMvc
 @Configuration
 public class MyWebMvcConfigurerAdapte extends WebMvcConfigurerAdapter {

  @Override
  public void configureViewResolvers(ViewResolverRegistry registry) {
   registry.jsp("/WEB-INF/jsp/", ".jsp");
   registry.enableContentNegotiation(new MappingJackson2JsonView());
  }

  @Override
  public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
   configurer.favorPathExtension(true)
     .ignoreAcceptHeader(true)
     .parameterName("mediaType")
     .defaultContentType(MediaType.TEXT_HTML)
     .mediaType("html", MediaType.TEXT_HTML)
     .mediaType("json", MediaType.APPLICATION_JSON);
  }
 }

controller的代码如下:

 @Controller
 public class ExampleController {
   @RequestMapping("/test")
   public ModelAndView test() {
   Map<String, String> map = new HashMap();
   map.put("哈哈", "哈哈哈哈");
   map.put("呵呵", "呵呵呵呵");
   return new ModelAndView("test", map);
  }
 }

在WEB-INF/jsp目录下创建一个test.jsp文件,内容随意。现在启动tomcat,在浏览器输入以下链接:http://localhost:8080/test.json,浏览器内容返回如下:

{
 "哈哈":"哈哈哈哈",
 "呵呵":"呵呵呵呵"
}

在浏览器输入http://localhost:8080/test 或者http://localhost:8080/test.html,内容返回如下:

this is test.jsp

显然,两次使用了不同的视图解析器,那么底层到底发生了什么?在配置里我们注册了两个视图解析器:

ContentNegotiatingViewResolver 和 InternalResourceViewResolver,还有一个默认视图:MappingJackson2JsonView。controller执行完毕之后返回一个ModelAndView,其中视图的名称为example1。

1.返回首先会交给ContentNegotiatingViewResolver 进行视图解析处理,而ContentNegotiatingViewResolver 会先把视图名example1交给它持有的所有ViewResolver尝试进行解析(本实例中只有InternalResourceViewResolver),

2.根据请求的mediaType,再将example1.mediaType(这里是example1.json 和example1.html)作为视图名让所有视图解析器解析一遍,两步解析完毕之后会获得一堆候选的List<View> 再加上默认的MappingJackson2JsonView ,

3.根据请求的media type从候选的List<View> 中选择一个最佳的返回,至此视图解析完毕。

现在就可以理解上例中为何请求链接加上.json 和不.json 结果会不一样。当加上.json 时,表示请求的media type 为MediaType.APPLICATION_JSON,而InternalResourceViewResolver 解析出来的视图的ContentType与其不符,而与MappingJackson2JsonView 的ContentType相符,所以选择了MappingJackson2JsonView 作为视图返回。当不加.json 请求时,默认的media type 为MediaType.TEXT_HTML,所以就使用了InternalResourceViewResolver解析出来的视图作为返回值了。我想看到这里你已经大致可以自定义视图了。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Spring Boot配置接口WebMvcConfigurer的实现

    WebMvcConfigurer配置类其实是Spring内部的一种配置方式,采用JavaBean的形式来代替传统的xml配置文件形式进行针对框架个性化定制.基于java-based方式的spring mvc配置,需要创建一个配置类并实现WebMvcConfigurer 接口,WebMvcConfigurerAdapter 抽象类是对WebMvcConfigurer接口的简单抽象(增加了一些默认实现),但在在SpringBoot2.0及Spring5.0中WebMvcConfigurerAdapt

  • Spring Boot 集成接口管理工具 Knife4j

    目录 前言 集成过程 创建 Spring Boot 项目 添加依赖 配置添加 编写 Controller 层 启动测试 踩过的坑 空指针异常 请求路径未找到 总结 前言 之前介绍了如何在 Spring Boot 中集成 Swagger2 和 Swagger3,对于我们日常的接口管理已经够用了.但是作为一个颜值党,无论是 Swagger2 还是 Swagger3,都难以满足我们的审美.而且 Swagger2 和 Swagger3 都已经好久没更新了,更新还是比较慢的. 偶然之间发现了一个国产的接口

  • 通过Spring Boot配置动态数据源访问多个数据库的实现代码

    之前写过一篇博客<Spring+Mybatis+Mysql搭建分布式数据库访问框架>描述如何通过Spring+Mybatis配置动态数据源访问多个数据库.但是之前的方案有一些限制(原博客中也描述了):只适用于数据库数量不多且固定的情况.针对数据库动态增加的情况无能为力. 下面讲的方案能支持数据库动态增删,数量不限. 数据库环境准备 下面一Mysql为例,先在本地建3个数据库用于测试.需要说明的是本方案不限数据库数量,支持不同的数据库部署在不同的服务器上.如图所示db_project_001.d

  • spring boot配置MySQL数据库连接、Hikari连接池和Mybatis的简单配置方法

    此方法为极简配置,支持MySQL数据库多库连接.支持Hikari连接池.支持MyBatis(包括Dao类和xml文件位置的配置). 1.pom.xml中引入依赖: <!-- Begin of DB related --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId>

  • Spring Boot配置过滤器的2种方式示例

    前言 过滤器(Filter)是Servlet中常用的技术,可以实现用户在访问某个目标资源之前,对访问的请求和响应进行拦截,常用的场景有登录校验.权限控制.敏感词过滤等,下面介绍下Spring Boot配置过滤器的两种方式. 一.@WebFilter注解方式 使用@WebFilter注解为声明当前类为filter,第一个参数为该filter起一个名字,第二个参数为说明要拦截的请求地址,当前类需要实现Filter接口,里面有三个方法,分别为过滤器初始化.过滤方法和过滤器销毁. @Slf4j @Web

  • spring boot配置拦截器代码实例

    这篇文章主要介绍了spring boot配置拦截器代码实例,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 首先引入web模块的依赖: 复制代码 <!-- spring boot web 组件 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</ar

  • Spring boot配置 swagger的示例代码

    为什么使用Swagger 在实际开发中我们作为后端总是给前端或者其他系统提供接口,每次写完代码之后不可避免的都需要去写接口文档,首先写接口文档是一件繁琐的事,其次由接口到接口文档需要对字段.甚至是排版等.再加上如果我们是为多个系统提供接口时可能还需要按照不同系统的要求去书写文档,那么有没有一种方式让我们在开发阶段就给前端提供好接口文档,甚至我们可以把生成好的接口文档暴露出去供其他系统调用,那么这样我只需要一份代码即可. Spring boot配置 swagger 1.导入maven依赖 <!--

  • Spring Boot 配置 Quartz 定时任务的方法

    Quartz有四个核心概念: Job:是一个接口,只定义一个方法 execute(JobExecutionContext context),在实现接口的 execute 方法中编写所需要定时执行的 Job(任务) Double slongitude = Double.valueOf(jobExecutionContext.getJobDetail().getJobDataMap().get("slongitude").toString()); JobDetail:Quartz 每次调度

  • 详解Spring Boot配置排序依赖技巧

    本文主要介绍了Spring Boot配置排序依赖技巧,分享给大家,具体如下: Spring Boot - 被错误使用的注解 我自己曾经在 Spring Boot 中集成通用 Mapper 时,写过下面的代码: @Configuration @AutoConfigureAfter(MyBatisConfig.class) public class MyBatisMapperScannerConfig { //其他 } 这种用法我参考的 mybatis-spring-boot-starter. 由于

  • 详解spring boot配置 ssl

    ssl协议位于tcp/ip协议与各种应用协议之间,为数据通信提供安全支持. ssl协议分为两层: ssl记录协议,它建立在可靠传输协议之上,为高层协议提供数据封装.压缩.加密等基本功能支持. ssl握手协议,它建立在ssl记录协议之上,用于实际数据传输开始前,通信双方进行身份认证.协商加密算法.交换加密密钥等 基于B/S的web应用,是通过https来实现ssl的.https是http的安全版,即在http下加入ssl层,https的安全基础是ssl: 我们开始在spring boot中使用ss

随机推荐