Add support for testing overriden DispatcherServlet instances in mvc test framework [SPR-10426]

[spring-projects-issues]

Anthony Gerrard opened SPR-10426 and commented

Status Quo

Because the MVC test framework uses a subclass of DispatcherServlet it makes it difficult to test functionality if your application overrides the DispatcherServlet.

Proposal

It would be nice if you could pass in a DispatcherServlet say like this:

this.mockMvc = MockMvcBuilders
                .webAppContextSetup(applicationContext, new MyDispatcherServlet())
                .build();

You'd obviously need to tweak what is done under the covers. Maybe switching TestDispatcherServlet to be a decorator?

---

Affects: 3.2.2

Issue Links:

• Improve support for custom HTTP verbs in Spring MVC Test [SPR-13719] #18292 Improve support for custom HTTP verbs in Spring MVC Test

1 votes, 4 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

TestDispatcherServlet extends in order to save processing state, like what handler was used, and make that available for declaring expectations. Can you elaborate on your custom extension fo the DispatcherServlet? Is it something straight-forward like allowing custom HTTP methods or something more extensive? What I'm wondering is whether making the TestDispatcherServlet public and allowing you to configure a sub-class of it would work, see #18292? Also there are some changes coming to allow custom HTTP verbs by default, see #9476.

[spring-projects-issues]

Kamill Sokol commented

Due to resolved issue #9476 #18292 doesn't require a custom TestDispatcherServlet anymore. Maybe Spring 4.3.0.BUILD-SNAPSHOT resolves reason for this issue too.

[spring-projects-issues]

Rossen Stoyanchev commented

Anthony Gerrard, could you elaborate on the reason for extending the DispatcherServlet?

[spring-projects-issues]

Anthony Gerrard commented

It's quite a while ago I did this. Spring 3.2 / Servlet 3.0. Looking back at the code there's two reasons:

1. using the WebServlet annotation to avoid having to add a servlet definition into web.xml

    
@WebServlet(name="spring-dispatcher", loadOnStartup=1, urlPatterns={"/"},
        initParams={@WebInitParam(name="contextConfigLocation", value="/WEB-INF/spring/spring-dispatcher-servlet.xml")})

2. enforce that semi colon content is stripped from request URIs for handler mappings (we use matrix variables for a/b testing and this was required after a spring 3.2 upgrade)

    
@Override
    protected void initStrategies(ApplicationContext context) {
        super.initStrategies(context);
        for (AbstractHandlerMapping handlerMapping : BeanFactoryUtils.beansOfTypeIncludingAncestors(
                context, AbstractHandlerMapping.class, true, false).values()) {
            
            handlerMapping.setRemoveSemicolonContent(true);
        }        
    }

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for the response. The first reason is not needed for Spring MVC Test so it's down to the second. The removeSemiColonContent is really a UrlPathHelper property which is exposed in the MVC Namespace and Java config (see reference) or otherwise, if not using either, could also be set with BeanPostProcessor. That might be all that's needed to make your use case work.

As I mentioned above there is actually no easy way to get at what handler was used to handle the request, what Exception was resolved (if any), and ModelAndView resulted, without sub-classing. There are other ways for sure, for example expectations on the handler, ModelAndView, and resolved exception would simply not be available if registering a custom DispatcherServlet, or perhaps the DispatcherServlet could expose them as request attributes for testing purposes. Still none of these options are favorites so I'd rather not do anything unless there is a good reason.

[spring-projects-issues]

Rossen Stoyanchev commented

Anthony Gerrard, I'm resolving this for now since as of 4.0.3 it is possible to configure removeSemicolonContent through the MVC Java config and XML namespace. If you are on 3.2.x as the ticket indicates you can switch to using a BeanPostProcessor to do the same. That should remove the need for sub-classing TestDispatcherServlet which in principal isn't a bad idea but presents challenges for the assertions we enable. Feel free to comment or re-open.