Spring Boot配置接口WebMvcConfigurer的實(shí)現(xiàn)
WebMvcConfigurer配置類其實(shí)是Spring內(nèi)部的一種配置方式,采用JavaBean的形式來代替?zhèn)鹘y(tǒng)的xml配置文件形式進(jìn)行針對框架個(gè)性化定制。基于java-based方式的spring mvc配置,需要?jiǎng)?chuàng)建一個(gè)配置類并實(shí)現(xiàn)WebMvcConfigurer 接口,WebMvcConfigurerAdapter 抽象類是對WebMvcConfigurer接口的簡單抽象(增加了一些默認(rèn)實(shí)現(xiàn)),但在在SpringBoot2.0及Spring5.0中WebMvcConfigurerAdapter已被廢棄 。官方推薦直接實(shí)現(xiàn)WebMvcConfigurer或者直接繼承WebMvcConfigurationSupport,方式一實(shí)現(xiàn)WebMvcConfigurer接口(推薦),方式二繼承WebMvcConfigurationSupport類,具體實(shí)現(xiàn)可看這篇文章。http://www.dbjr.com.cn/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();
}
接下來我們著重找?guī)讉€(gè)方法講解一下:
/* 攔截器配置 */ void addInterceptors(InterceptorRegistry var1); /* 視圖跳轉(zhuǎn)控制器 */ void addViewControllers(ViewControllerRegistry registry); /** *靜態(tài)資源處理 **/ void addResourceHandlers(ResourceHandlerRegistry registry); /* 默認(rèn)靜態(tài)資源處理器 */ void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer); /** * 這里配置視圖解析器 **/ void configureViewResolvers(ViewResolverRegistry registry); /* 配置內(nèi)容裁決的一些選項(xiàng)*/ void configureContentNegotiation(ContentNegotiationConfigurer configurer);
1、addInterceptors(InterceptorRegistry registry)
此方法用來專門注冊一個(gè)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請求的攔截。
當(dāng)spring boot版本升級為2.x時(shí),訪問靜態(tài)資源就會(huì)被HandlerInterceptor攔截,網(wǎng)上有很多處理辦法都是如下寫法
.excludePathPatterns("/index.html","/","/user/login","/static/**");
可惜本人在使用時(shí)一直不起作用,查看請求的路徑里并沒有/static/如圖:

于是我改成了"/js/**","/css/**","/images/**"這樣頁面內(nèi)容就可以正常訪問了,我的項(xiàng)目結(jié)構(gòu)如下:

2. 頁面跳轉(zhuǎn)addViewControllers
以前寫SpringMVC的時(shí)候,如果需要訪問一個(gè)頁面,必須要寫Controller類,然后再寫一個(gè)方法跳轉(zhuǎn)到頁面,感覺好麻煩,其實(shí)重寫WebMvcConfigurer中的addViewControllers方法即可達(dá)到效果了
/**
* 以前要訪問一個(gè)頁面需要先創(chuàng)建個(gè)Controller控制類,再寫方法跳轉(zhuǎn)到頁面
* 在這里配置后就不需要那么麻煩了,直接訪問http://localhost:8080/toLogin就跳轉(zhuǎn)到login.jsp頁面了
* @param registry
*/
@Override
public void addViewControllers(ViewControllerRegistry registry) {
registry.addViewController("/toLogin").setViewName("login");
}
值的指出的是,在這里重寫addViewControllers方法,并不會(huì)覆蓋WebMvcAutoConfiguration中的addViewControllers(在此方法中,Spring Boot將“/”映射至index.html),這也就意味著我們自己的配置和Spring Boot的自動(dòng)配置同時(shí)有效,這也是我們推薦添加自己的MVC配置的方式。
3. 自定義資源映射addResourceHandlers
比如,我們想自定義靜態(tài)資源映射目錄的話,只需重寫addResourceHandlers方法即可。
注:如果繼承WebMvcConfigurationSupport類實(shí)現(xiàn)配置時(shí)必須要重寫該方法,具體見其它文章
@Configuration
public class MyWebMvcConfigurerAdapter implements WebMvcConfigurer {
/**
* 配置靜態(tài)訪問資源
* @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");
}
此時(shí)會(huì)注冊一個(gè)默認(rèn)的Handler:DefaultServletHttpRequestHandler,這個(gè)Handler也是用來處理靜態(tài)文件的,它會(huì)嘗試映射/。當(dāng)DispatcherServelt映射/時(shí)(/ 和/ 是有區(qū)別的),并且沒有找到合適的Handler來處理請求時(shí),就會(huì)交給DefaultServletHttpRequestHandler 來處理。注意:這里的靜態(tài)資源是放置在web根目錄下,而非WEB-INF 下。
可能這里的描述有點(diǎn)不好懂(我自己也這么覺得),所以簡單舉個(gè)例子,例如:在webroot目錄下有一個(gè)圖片:1.png 我們知道Servelt規(guī)范中web根目錄(webroot)下的文件可以直接訪問的,但是由于DispatcherServlet配置了映射路徑是:/ ,它幾乎把所有的請求都攔截了,從而導(dǎo)致1.png 訪問不到,這時(shí)注冊一個(gè)DefaultServletHttpRequestHandler 就可以解決這個(gè)問題。其實(shí)可以理解為DispatcherServlet破壞了Servlet的一個(gè)特性(根目錄下的文件可以直接訪問),DefaultServletHttpRequestHandler是幫助回歸這個(gè)特性的。
5、configureViewResolvers(ViewResolverRegistry registry)
從方法名稱我們就能看出這個(gè)方法是用來配置視圖解析器的,該方法的參數(shù)ViewResolverRegistry 是一個(gè)注冊器,用來注冊你想自定義的視圖解析器等。ViewResolverRegistry 常用的幾個(gè)方法:
1).enableContentNegotiation()
/** 啟用內(nèi)容裁決視圖解析器*/
public void enableContentNegotiation(View... defaultViews) {
initContentNegotiatingViewResolver(defaultViews);
}
該方法會(huì)創(chuàng)建一個(gè)內(nèi)容裁決解析器ContentNegotiatingViewResolver ,該解析器不進(jìn)行具體視圖的解析,而是管理你注冊的所有視圖解析器,所有的視圖會(huì)先經(jīng)過它進(jìn)行解析,然后由它來決定具體使用哪個(gè)解析器進(jìn)行解析。具體的映射規(guī)則是根據(jù)請求的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);
}
該方法會(huì)注冊一個(gè)內(nèi)部資源視圖解析器InternalResourceViewResolver 顯然訪問的所有jsp都是它進(jìn)行解析的。該方法參數(shù)用來指定路徑的前綴和文件后綴,如:
registry.jsp("/WEB-INF/jsp/", ".jsp");
對于以上配置,假如返回的視圖名稱是example,它會(huì)返回/WEB-INF/jsp/example.jsp給前端,找不到則報(bào)404?! ?/p>
3). beanName()
public void beanName() {
BeanNameViewResolver resolver = new BeanNameViewResolver();
this.viewResolvers.add(resolver);
}
該方法會(huì)注冊一個(gè)BeanNameViewResolver 視圖解析器,這個(gè)解析器是干嘛的呢?它主要是將視圖名稱解析成對應(yīng)的bean。什么意思呢?假如返回的視圖名稱是example,它會(huì)到spring容器中找有沒有一個(gè)叫example的bean,并且這個(gè)bean是View.class類型的?如果有,返回這個(gè)bean?! ?/p>
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);
}
這個(gè)方法想必看名字就知道了,它就是用來注冊各種各樣的視圖解析器的,包括自己定義的。
6. configureContentNegotiation(ContentNegotiationConfigurer configurer)
上面我們講了configureViewResolvers 方法,假如在該方法中我們啟用了內(nèi)容裁決解析器,那么configureContentNegotiation(ContentNegotiationConfigurer configurer) 這個(gè)方法是專門用來配置內(nèi)容裁決的一些參數(shù)的。這個(gè)比較簡單,我們直接通過一個(gè)例子看:
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
/* 是否通過請求Url的擴(kuò)展名來決定media type */
configurer.favorPathExtension(true)
/* 不檢查Accept請求頭 */
.ignoreAcceptHeader(true)
.parameterName("mediaType")
/* 設(shè)置默認(rèn)的media yype */
.defaultContentType(MediaType.TEXT_HTML)
/* 請求以.html結(jié)尾的會(huì)被當(dāng)成MediaType.TEXT_HTML*/
.mediaType("html", MediaType.TEXT_HTML)
/* 請求以.json結(jié)尾的會(huì)被當(dāng)成MediaType.APPLICATION_JSON*/
.mediaType("json", MediaType.APPLICATION_JSON);
}
到這里我們就可以舉個(gè)例子來進(jìn)一步熟悉下我們上面講的知識(shí)了,假如我們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目錄下創(chuàng)建一個(gè)test.jsp文件,內(nèi)容隨意。現(xiàn)在啟動(dòng)tomcat,在瀏覽器輸入以下鏈接:http://localhost:8080/test.json,瀏覽器內(nèi)容返回如下:
{
"哈哈":"哈哈哈哈",
"呵呵":"呵呵呵呵"
}
在瀏覽器輸入http://localhost:8080/test 或者h(yuǎn)ttp://localhost:8080/test.html,內(nèi)容返回如下:
this is test.jsp
顯然,兩次使用了不同的視圖解析器,那么底層到底發(fā)生了什么?在配置里我們注冊了兩個(gè)視圖解析器:
ContentNegotiatingViewResolver 和 InternalResourceViewResolver,還有一個(gè)默認(rèn)視圖:MappingJackson2JsonView。controller執(zhí)行完畢之后返回一個(gè)ModelAndView,其中視圖的名稱為example1。
1.返回首先會(huì)交給ContentNegotiatingViewResolver 進(jìn)行視圖解析處理,而ContentNegotiatingViewResolver 會(huì)先把視圖名example1交給它持有的所有ViewResolver嘗試進(jìn)行解析(本實(shí)例中只有InternalResourceViewResolver),
2.根據(jù)請求的mediaType,再將example1.mediaType(這里是example1.json 和example1.html)作為視圖名讓所有視圖解析器解析一遍,兩步解析完畢之后會(huì)獲得一堆候選的List<View> 再加上默認(rèn)的MappingJackson2JsonView ,
3.根據(jù)請求的media type從候選的List<View> 中選擇一個(gè)最佳的返回,至此視圖解析完畢。
現(xiàn)在就可以理解上例中為何請求鏈接加上.json 和不.json 結(jié)果會(huì)不一樣。當(dāng)加上.json 時(shí),表示請求的media type 為MediaType.APPLICATION_JSON,而InternalResourceViewResolver 解析出來的視圖的ContentType與其不符,而與MappingJackson2JsonView 的ContentType相符,所以選擇了MappingJackson2JsonView 作為視圖返回。當(dāng)不加.json 請求時(shí),默認(rèn)的media type 為MediaType.TEXT_HTML,所以就使用了InternalResourceViewResolver解析出來的視圖作為返回值了。我想看到這里你已經(jīng)大致可以自定義視圖了。
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
spring+Jpa多數(shù)據(jù)源配置的方法示例
這篇文章主要介紹了spring+Jpa多數(shù)據(jù)源配置的方法示例,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-08-08
mybatis resultType自帶數(shù)據(jù)類型別名解讀
MyBatis為了簡化開發(fā),通過org.apache.ibatis.type.TypeAliasRegistry為常見類定義了別名,這些別名包括基本數(shù)據(jù)類型及其數(shù)組、集合類型等,如string對應(yīng)java.lang.String,int對應(yīng)java.lang.Integer等,此外,還有特殊前綴的別名如_int對應(yīng)int類型2024-10-10
Java實(shí)現(xiàn)簡單局域網(wǎng)聊天室
這篇文章主要為大家詳細(xì)介紹了Java實(shí)現(xiàn)簡單局域網(wǎng)聊天室,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2021-06-06

