Difference between WebMvcConfigurationSupport and WebMvcConfigurerAdapter

if you use ConfigurationSupport class get ready mind numbing hardwork when trying to serve static resources, because it does not work.

The answer is in the doc you referenced above:

If the customization options of WebMvcConfigurer do not expose something you need to configure, consider removing the @EnableWebMvc annotation and extending directly from WebMvcConfigurationSupport overriding selected @Bean methods

In short, if @EnableWebMvc works for you, there is no need to look any further.

I was recently solving this very same problem when configuring converters and it resulted in quite a long post.

By default Spring Boot uses its implementation of WebMvcConfigurationSupport and does a lot of auto-magic including finding all the WebMvcConfigurer and using them. There is one implementation provided by Boot already and you may add more. This results in seemingly confusing behaviour when the list of converters coming to configureMessageConverters in your implementation of WebMvcConfigurer is already pre-populated from previous configurer.

These types (WebMvcConfigurationSupport and WebMvcConfigurer) have also strikingly similar interface - but the first does NOT implement the other. The point is:

Support class searches for configurers and uses them + does something on its own.

If you extend from WebMvcConfigurationSupport you take over the configuration and while there are some things available that are not in WebMvcConfigurer (like addDefaultHttpMessageConverters) there is also tons of code from EnableWebMvcConfiguration and DelegatingWebMvcConfiguration that does not happen.

Both extending WebMvcConfigurationSupport or WebMvcConfigurer (not sure both at once makes much sense) have their valid usages, but with extending the support class you take over the process much more and lose a lot of "opinionated" Spring Boot functionality.