CODEWITHSUNDEEP
springspring-mvc
dtrunk
dtrunk

Reputation: 4805

Difference between WebMvcConfigurationSupport and WebMvcConfigurerAdapter

I would like to add resource handlers. In the forum they use WebMvcConfigurationSupport: http://forum.springsource.org/showthread.php?116068-How-to-configure-lt-mvc-resources-gt-mapping-to-take-precedence-over-RequestMapping&p=384066#post384066

and docs say WebMvcConfigurerAdapter: http://static.springsource.org/spring/docs/3.2.x/javadoc-api/org/springframework/web/servlet/config/annotation/EnableWebMvc.html

What's the difference and which one to use? Both has the addResourceHandlers method I need.

This is my current class:

@Configuration
@EnableWebMvc
public class WebMvcConfig extends WebMvcConfigurerAdapter {
    public @Override void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/resources/**").addResourceLocations("/resources");
    }

    public @Bean TilesViewResolver tilesViewResolver() {
        return new TilesViewResolver();
    }

    public @Bean TilesConfigurer tilesConfigurer() {
        TilesConfigurer ret = new TilesConfigurer();
        ret.setDefinitions(new String[] { "classpath:tiles.xml" });
        return ret;
    }
}

Upvotes: 42

Views: 35930

Answers (4)

virgo47
virgo47

Reputation: 2333

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.

Upvotes: 8

user1363516
user1363516

Reputation: 358

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

Upvotes: 7

Pushpendra Jaiswal
Pushpendra Jaiswal

Reputation: 470

Its better to extend WebMvcConfigurationSupport. It provides more customization options and also works fine with

configureMessageConverters(List<HttpMessageConverter<?>> converters)

cause you can add these convertors using

addDefaultHttpMessageConverters(converters);

that is not available with WebMvcConfigurerAdapter.

Click [here] How to configure MappingJacksonHttpMessageConverter while using spring annotation-based configuration?

If you extend WebMvcConfigurerAdapter, it behaves strangely with configuring Jackson and Jaxb. That happened with me !!!

Upvotes: 3

Rossen Stoyanchev
Rossen Stoyanchev

Reputation: 5008

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.

Upvotes: 28

Related Questions