从本质上来看,Bean 之所以拥有高可扩展性,这主要得益于@Import
、@Conditional
和 Callback Interface
。@Import 注解为 Bean 带来了灵活的可插拔机制,比如众多的 EnableXXX 注解;@Conditional 注解为 Bean 带来了条件化的激活机制,比如 @ConditionalOnMissingBean 注解;Callback Interface 为 Bean 带来了灵活的定制化机制,比如 BeanPostProcessor、WebMvcConfigurer 等。
WebMvcConfigurationSupport
声明了以支撑 Spring MVC 功能流转的一些 Bean,比如 HandlerMapping、HandlerAdapter、HandlerExceptionResolver 和 PathMatcher 等。在这些 Bean 的声明逻辑中,往往涉及对若干 protected 方法的调用,这些 protected 方法自然是为子类预留的,方便子类去做一些个性化拓展,官方从 WebMvcConfigurationSupport 这些方法中挑选了一些并将其封装为WebMvcConfigurer
回调接口。WebMvcConfigurer 是定制化 Spring MVC 的统一入口,在日常工作中,好像只有在注册 HandlerInterceptor 拦截器时才会和它打交道,但它对 Spring MVC 的定制化能力远不止如此:
public interface WebMvcConfigurer {
default void configurePathMatch(PathMatchConfigurer configurer) {}
default void configureContentNegotiation(ContentNegotiationConfigurer configurer) {}
default void configureAsyncSupport(AsyncSupportConfigurer configurer) {}
default void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {}
default void addFormatters(FormatterRegistry registry) {}
default void addInterceptors(InterceptorRegistry registry) {}
default void addResourceHandlers(ResourceHandlerRegistry registry) {}
default void addCorsMappings(CorsRegistry registry) {}
default void addViewControllers(ViewControllerRegistry registry) {}
default void configureViewResolvers(ViewResolverRegistry registry) {}
default void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {}
default void addReturnValueHandlers(List<HandlerMethodReturnValueHandler> handlers) {}
default void configureMessageConverters(List<HttpMessageConverter<?>> converters) {}
default void extendMessageConverters(List<HttpMessageConverter<?>> converters) {}
default void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {}
default void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {}
default Validator getValidator() {return null;}
default MessageCodesResolver getMessageCodesResolver() {return null;}
}
每个方法都由 default 关键字修饰,也就不需要什么适配器了,因此WebMvcConfigurerAdapter
被拿掉了。
在一个 Spring MVC 应用中,WebMvcConfigurer 也许有多个不同诉求的实现类,为了统一、方便地回调这些 WebMvcConfigurer Bean,Spring 提供了WebMvcConfigurerComposite
:
public class WebMvcConfigurerComposite implements WebMvcConfigurer {
private final List<WebMvcConfigurer> delegates = new ArrayList<>();
public void addWebMvcConfigurers(List<WebMvcConfigurer> configurers) {
if (!CollectionUtils.isEmpty(configurers)) {
this.delegates.addAll(configurers);
}
}
@Override
public void configurePathMatch(PathMatchConfigurer configurer) {
for (WebMvcConfigurer delegate : this.delegates) {
delegate.configurePathMatch(configurer);
}
}
@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
for (WebMvcConfigurer delegate : this.delegates) {
delegate.configureContentNegotiation(configurer);
}
}
// ···
}
有了 WebMvcConfigurerComposite 这个复合类,后续直接通过一个 WebMvcConfigurerComposite 即可实现与所有的 WebMvcConfigurer 交互,也不用搞得遍地都是 for 循环,挺好。为了兑现 WebMvcConfigurerComposite 的价值,首先要搞清楚“通过一个 WebMvcConfigurerComposite 即可实现与所有的 WebMvcConfigurer 交互”这个逻辑应该放在哪里?非 WebMvcConfigurationSupport 子类莫属,这个子类就是DelegatingWebMvcConfiguration
:
@Configuration(proxyBeanMethods = false)
public class DelegatingWebMvcConfiguration extends WebMvcConfigurationSupport {
private final WebMvcConfigurerComposite configurers = new WebMvcConfigurerComposite();
@Autowired(required = false)
public void setConfigurers(List<WebMvcConfigurer> configurers) {
if (!CollectionUtils.isEmpty(configurers)) {
this.configurers.addWebMvcConfigurers(configurers);
}
}
@Override
protected void configurePathMatch(PathMatchConfigurer configurer) {
this.configurers.configurePathMatch(configurer);
}
@Override
protected void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
this.configurers.configureContentNegotiation(configurer);
}
// ···
}
Spring Boot 针对 Spring MVC 提供了自动配置类WebMvcAutoConfiguration
,这里面依然是通过 DelegatingWebMvcConfiguration 来声明那些以支撑 Spring MVC 功能运转的 Bean!
WebMvcConfigurer 的套路大家学会了吗?可以尝试在自己封装的 starter 组件上用起来!!!