WebMvcConfigurationSupport and WebMvcConfigurer

WebMvc disposed in the spring when the two methods, one is inherited WebMvcConfigurationSupport, overwriting a corresponding method which, there is a succession of sub WebMvcConfigurerAdapter WebMvcConfigurer abstract class, which is also a corresponding method of rewriting, but requires the configuration class Add @EnableWebMvc comment. It is these two classes directly to do with it?
  Careful developers will find an empty method WebMvcConfigurationSupport subclass can override those of all, this is just an extension of the class description WebMvcConfigurer WebMvcConfigurationSupport in WebMvcConfigurer, it does not extend new features, just to make it easier for users to add custom security Custom configuration, why is it safe? Because if the direct successor WebMvcConfigurationSupport, the user can override the default configuration, if not very clear on the principles developed by accidentally rewrote the default configuration, springmvc likely related functions will not take effect, is an unsafe behavior. But if it is inherited WebMvcConfigurerAdapter, then the developer is in default add custom configuration based on the configuration, relatively safer, but to add an extra @EnableWebMvc comment. From this perspective, best practices or inherited WebMvcConfigurerAdapter, as follows

@Configuration
@EnableWebMvc
public class WebConfig extends WebMvcConfigurerAdapter {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //添加自定义拦截器
        registry.addInterceptor();
    }
}

1. Why WebMvcConfigurer achieve to add @EnableWebMvc
     imported DelegatingWebMvcConfiguration class on @EnableWebMvc annotation class, which is a subclass of WebMvcConfigurationSupport, in addition to instantiate the class instance WebMvcConfigurationSupport outside, and the other role is to collect all WebMvcConfigurer achieve the BeanFactory, the collection in the WebMvcConfigurerComposite in WebMvcConfigurationSupport instantiation calls are these implementations, the corresponding instance passed these implementations are for developers to add custom configuration on this basis. This is on WebMvcConfigurerAdapter subclasses to add @EnableWebMvc reasons, because first instantiation WebMvcConfigurationSupport.

2. Why can implement multiple WebMvcConfigurer of existence?
     In general, an application of a WebMvcConfigurer enough, is not designed to collect more than a bit redundant? From the point of view springboot autoconfigure mechanism is not redundant, but more flexible, for example, I write a mybatis of AutoConfiguration and JPA AutoConfiguration, I can achieve a WebMvcConfigurer defined in different AutoConfiguration inside, which only configurations related to mybatis or JPA configuration, this requires that enabled that do not need to manually convert the code by commenting mybatis and JPA, Note: in springboot custom WebMvcConfigurer achieve the configuration class is not necessary to add @EnableWebMvc because springboot been instantiated WebMvcConfigurationSupport, If you add the annotation, the default configuration WebMvcConfigurationSupport class is not in force, it is mainly user-defined, general recommendations or not to override the default good.

When Spring Boot inherit WebMvcConfigurerAdapter with their own configuration class after 2.0, idea will prompt the class is obsolete.

Normally we use two alternative of the following:

• Achieve WebMvcConfigurer  
• Inheritance WebMvcConfigurationSupport

But found cause some problems inherited WebMvcConfigurationSupport

Prior to this, we look at WebMvc automatic configuration WebMvcAutoConfiguration class definition:

Note that the red line to ring up the key statement:

@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)

See this line can understand, the original SpringBoot made this restriction only when WebMvcConfigurationSupport class does not exist to take effect WebMvc automated configuration, automatic configuration WebMvc class defines not only the classpath: / META-INF / resources /, classpath: / resources /, classpath: / static /, classpath: mapping / public / other path, the configuration information also defines the beginning of the file spring.mvc like.

When WebMvcAutoConfiguration not take effect will lead to the following questions:
1.WebMvcProperties and ResourceProperties failure

Since the properties of two classes are arranged in the WebMvcAutoConfiguration

When WebMvc autoconfiguration fails (WebMvcAutoConfiguration automated configuration), it will lead to not view and return to the resolver can not resolve the corresponding view

2. HttpMessageConverter the class path failure

Such as: StringHttpMessageConverterConfiguration, MappingJackson2HttpMessageConverter, because HttpMessageConverters held in all the instances of HttpMessageConverter in WebMvcAutoConfigurationAdapter will inject HttpMessageConverters, so when WebMvcAutoConfigurationAdapter not loaded, it will fail, resulting in indirect spring.http.encoding.charset and spring.jackson. date-format illusion of failure.

Such as: StringHttpMessageConverter spring.http.encoding.charset use configuration, is a default encoding: ISO-8859-1