Regression: SpringHandlerInstantiator breaks stand-alone support in the MVC Test framework [SPR-13375]

[spring-projects-issues]

Sam Brannen opened SPR-13375 and commented

The SpringHandlerInstantiator introduced in #15394 always attempts to create new beans using its AutowireCapableBeanFactory. In the case of a StubWebApplicationContext, however, this results in an UnsupportedOperationException being thrown.

This behavior breaks support for JSON serialization in conjunction with the default configuration of the MockMvcBuilders.standaloneSetup() support in the Spring MVC Test framework since it internally uses a StubWebApplicationContext.

See the linked discussion on Stack Overflow for details.

Analysis

The following code in WebMvcConfigurationSupport.addDefaultHttpMessageConverters() is what causes this behavior:

if (jackson2Present) {
	ObjectMapper objectMapper = Jackson2ObjectMapperBuilder.json().applicationContext(this.applicationContext).build();
	messageConverters.add(new MappingJackson2HttpMessageConverter(objectMapper));
}

The fact that it supplies the ApplicationContext results in a SpringHandlerInstantiator being created in Jackson2ObjectMapperBuilder.configure(), even though a SpringHandlerInstantiator makes no sense for the stand-alone test setup in MVC Test.

---

Affects: 4.1.3

Reference URL: http://stackoverflow.com/questions/32101611/spring-mockmvc-unsupportedoperationexception-after-upgrading-to-new-spring-versi/32140898

Referenced from: commits spring-attic/spring-framework-issues@028ace9

Backported to: 4.1.8

0 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

Hmm, we should consider a revision of StubWebApplicationContext here, simply creating instances without any actual autowiring... Not sure whether I want any AutowireCapableBeanFactory calls in production code to be defensive about UnsupportedOperationException.

Juergen

[spring-projects-issues]

Sam Brannen commented

FYI: I updated my response on Stack Overflow.

[spring-projects-issues]

Sam Brannen commented

Daniel Lynch, yes, you should be able to work around this issue by registering your own MappingJackson2HttpMessageConverter via StandaloneMockMvcBuilder.setMessageConverters().

See my answer on the linked Stack Overflow discussion for details.

Something like the following should work:

ObjectMapper objectMapper = Jackson2ObjectMapperBuilder.json().build();

mockMvc = MockMvcBuilders.standaloneSetup(controller).setMessageConverters(new MappingJackson2HttpMessageConverter(objectMapper)).build();

Please let us know if that works for you!

[spring-projects-issues]

Sam Brannen commented

Juergen Hoeller, agreed: a revision of StubWebApplicationContext would likely be the more robust solution.

[spring-projects-issues]

Daniel Lynch commented

Sam Brannen, thank you, your suggestion did work.

[spring-projects-issues]

Sam Brannen commented

Daniel Lynch, great!

We appreciate the feedback.

[spring-projects-issues]

Juergen Hoeller commented

Sébastien Deleuze, I'll put this on my plate since it's really just about StubWebApplicationContext's implementation at this point.

Juergen

[spring-projects-issues]

Sébastien Deleuze commented

Juergen Hoeller Feel free to have a look to this repro project and reuse this commit not yet merged in master if you think this is ok.

<T> T createBean(Class<T> beanClass) is the only one needed, but I also updated Object createBean(Class beanClass, int autowireMode, boolean dependencyCheck) to be consistent, even if we are just creating bean instances without any autowiring.