Ensure registration of Jackson modules in the environment of an embedded Tomcat

[jonbe242]

Separate the configuration/creation of the default ObjectMapper bean from the registration of Jackson modules.
This is to avoid circular creations of the default ObjectMapper bean (and thus failing to obtain the ObjectMapper and registering the module(s)).

Sorry for not writing any tests to verify this, but I'm still new to Spring Boot and don't know yet how to write such a test with the embedded Tomcat.

[dsyer]

Thanks. Did you fill in the contributors agreement (link in README).

[jonbe242]

It's done now.

[dsyer]

Great. Can you explain the problem you are solving a bit more (or write a test: there are plenty of existing tests to crib from)? What does it have to so with Tomcat?

[jonbe242]

The problem occured when trying out Spring Boot and Java 8 and writing a simple REST controller returning a bean with JSR-310 fields (ZonedDateTime). The fields weren't serialized to numbers as expected, and it didn't help adding the Jackson JSR-310 module in the classpath. I tested defining my own ObjectMapper bean and manually registering the module which worked.

Getting annoyed by by the missmatch between the documentation and the behaviour I started to debug.

While debugging I noticed that the EmbeddedWebApplicationContext first triggers the creation of ServletContextInitializing beans which started a chain of bean creations (requestContextListener -> [...]WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter -> messageConverters -> HttpMessageConvertersAutoConfiguration -> mappingJackson2HttpMessageConverter jacksonObjectMapper -> JacksonAutoConfiguration). The JacksonAutoConfiguration's @PostConstruct then triggered another getBean for the jacksonObjectMapper bean which caused an BeanCurrentlyInCreationException and the jacksonObjectMapper bean was never available in the PostConstruct and thus no object mapper was available to register the JSR-310 Jackson module.

The issue is from this observation seems to bean bean creation order. I'm not that familiar with the difference between EmbeddedWebApplicationContext and AnnotationConfigApplicationContext with respect to this.

So my solution is to separate the creation of the jacksonObjectMapper from the registration of Jackson modules as they where dependent via the @PostConstruct method.

[dsyer]

OK that makes sense. It's a bug in the configuration, so thanks for the analysis. A test case would be awesome still.

[jonbe242]

Thanks for the pull. I'll try to create a test case.

[jonbe242]

Now I have written a test that exposes the bug but it is uggly:
I defined a new DefaultListableBeanFactory that in preInstantiateSingletons instantiates the jacksonObjectMapper bean before instantiating any other bean, to simulate the observed behavior in EmbeddedWebApplicationContext.

I looked into using EmbeddedWebApplicationContext instead of AnnotationConfigApplicationContext in the test, but that doesn't help much regarding the readability of the test.

Do you have any ideas for a better test approach?