Despite having a Jackson JDK 8 module bean available in the context, deserializing a request having an Optional<String> field fails with an error indicating that the object mapper in use does not have the module installed. The attached git bundle has a maven project and a unit test to reproduce the problem. The unit test demonstrates that the object mapper available from the context does have the module installed (by deserializing a JSON string into an object having an Optional<String> field), which seems to indicate that the http message handling is using a different object mapper that doesn't have the module installed.
We're only registering Jackson's general JDK 8 module by default as of Spring 4.2, so I suppose we're talking about a manually registered module here... with multiple ObjectMappers in use at runtime, and only one of them having the manual module registration applied?
The code registers the module as a bean in the application context, which the documentation describes as a way to make the module available globally. I think the worse problem is that the object mapper in use by the MVC stack for deserializing requests is not picking up such globally-registered modules. Why doesn't the MVC stack just use the global object mapper bean? That seems the simplest way to let REST controllers customize their JSON handling.
ObjectMapper customization by providing a bean is the Spring Boot approach. Regular Spring MVC application, or Spring Boot applications using @EnableWebMvc should customize the message converters as described in this article.
Could you check what kind of web configuration your application is using?