Spring Boot 配置介面 WebMvcConfigurer

JavaEdge發表於2019-01-31
Spring BootWebMVC

0 聯絡我

Spring Boot 配置介面 WebMvcConfigurer

1.Java開發技術交流Q群

2.完整部落格連結

3.個人知乎

4.gayhub

1 簡介

WebMvcConfigurer配置類其實是Spring內部的一種配置方式，採用JavaBean的形式來代替傳統的xml配置檔案形式進行鍼對框架個性化定製
基於java-based方式的spring mvc配置，需要建立一個配置類並實現WebMvcConfigurer 介面
WebMvcConfigurerAdapter 抽象類是對WebMvcConfigurer介面的簡單抽象（增加了一些預設實現），但在在SpringBoot2.0及Spring5.0中WebMvcConfigurerAdapter已被廢棄 。
官方推薦直接實現WebMvcConfigurer或者直接繼承WebMvcConfigurationSupport

  • 方式一實現WebMvcConfigurer介面（推薦）
  • 方式二繼承WebMvcConfigurationSupport類
Spring Boot 配置介面 WebMvcConfigurer

2 重點方法講解

/* 攔截器配置 */
void addInterceptors(InterceptorRegistry var1);
/* 檢視跳轉控制器 */
void addViewControllers(ViewControllerRegistry registry);
/**
  *靜態資源處理
  */
void addResourceHandlers(ResourceHandlerRegistry registry);
/* 預設靜態資源處理器 */
void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer);
/**
  * 這裡配置檢視解析器
  */
void configureViewResolvers(ViewResolverRegistry registry);
/* 配置內容裁決的一些選項*/
void configureContentNegotiation(ContentNegotiationConfigurer configurer);複製程式碼

2.1 addInterceptors(InterceptorRegistry registry)

專門註冊一個Interceptor,如HandlerInterceptorAdapter

Spring Boot 配置介面 WebMvcConfigurer

  • addPathPatterns("/**")
    對所有請求都攔截,但是排除了/toLogin和/login請求的攔截

當Spring Boot版本升級為2.x時,訪問靜態資源就會被HandlerInterceptor攔截,網上有很多處理辦法都是如下寫法

.excludePathPatterns("/index.html","/","/user/login","/static/**");複製程式碼

可有人說在使用時一直不起作用，檢視請求的路徑裡並沒有/static/如圖：


Spring Boot 配置介面 WebMvcConfigurer

於是改成

"/js/**","/css/**","/images/**"複製程式碼

這樣頁面內容就可以正常訪問了，他的專案結構如下：


Spring Boot 配置介面 WebMvcConfigurer

2.2 頁面跳轉 - addViewControllers

以前寫SpringMVC的時候，如果需要訪問一個頁面，必須要寫Controller類，然後再寫一個方法跳轉到頁面，感覺麻煩
其實重寫WebMvcConfigurer中的addViewControllers方法即可同效

Spring Boot 配置介面 WebMvcConfigurer

在這裡重寫addViewControllers,並不會覆蓋WebMvcAutoConfiguration中的addViewControllers（在此方法中，Spring Boot將“/”對映至index.html）
這也就意味著我們自己的配置和Spring Boot的自動配置同時有效，這也是我們推薦新增自己的MVC配置的方式。

2.3 自定義資源對映 - addResourceHandlers

欲自定義靜態資源對映目錄時,只需重寫addResourceHandlers.

注：如果繼承WebMvcConfigurationSupport類實現配置時必須要重寫該方法

Spring Boot 配置介面 WebMvcConfigurer

通過addResourceHandler新增對映路徑
然後通過addResourceLocations來指定路徑
我們訪問自定義my資料夾中的elephant.jpg 圖片的地址為
http://localhost:8080/my/elephant.jpg

  • 指定外部的目錄也很簡單，直接addResourceLocations
    Spring Boot 配置介面 WebMvcConfigurer

    addResourceLocations指的是檔案放置的目錄
    addResoureHandler指的是對外暴露的訪問路徑

2.4 configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer)

Spring Boot 配置介面 WebMvcConfigurer
  • 會註冊一個預設的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 常用的幾個方法：

１)．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);
}複製程式碼

這個方法想必看名字就知道了，它就是用來註冊各種各樣的檢視解析器的，包括自己定義的。

  1. 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解析出來的檢視作為返回值了。我想看到這裡你已經大致可以自定義檢視了。

相關文章