Bootstrap ObjectMapper not used in Jersey MessageBodyWriter

Dropwizard’s bootstrap object has an ObjectMapper in it that we’ve been trying to get to understand java8 datatypes (Optional / DateTime / etc). Initially we thought the dropwizard-java8 bundle would do this for us, as it’s setting up bootstrap.getObjectMapper() with the appropriate jackson modules, and allows us to return Optional resources. However, in order to return objects that contain Optionals it appears we need to do the following in our Application’s run() method:

JacksonJaxbJsonProvider provider = new JacksonJaxbJsonProvider();
provider.setMapper(objectMapperWithAppropriateModules);
environment.jersey().register(provider); 

It feels like a bug in dropwizard the the boostrap ObjectMapper is not being used by the reflection-instantiated JacksonJaxbJsonProvider? We’re seeing this behavior with Dropwizard 0.9.1 and dropwizard-java8 0.9.0-1

[RobeEW]

FWIW, a work around is to turn auto discovery off: environment.jersey().property(CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE, Boolean.TRUE);

This needs to be done for any jersey http clients you build, too:

new JerseyClientBuilder(environment)
            .withProperty(CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE, Boolean.TRUE)
            .build('main');

(Incidentally, doesn’t everyone love double negative flags?)

[oillio]

Jersey rejected my request to allow inheriting: https://github.com/jersey/jersey/pull/221

Looking a little deeper, I am wondering why Dropwizard defines a JacksonJaxbJsonProvider at all?

It is currently being used to define the ObjectMapper to be used. From what I understand, Jersey recommends this to be defined through an ObjectMapperProvider, such as in this example: https://github.com/jersey/jersey/blob/2.23.1/examples/json-jackson/src/main/java/org/glassfish/jersey/examples/jackson/MyObjectMapperProvider.java

The JsonProvider is also adding support the @JsonIgnoreType annotation. There may be another way to provide this as well.

I would be happy to dig deeper into the possibility of replacing JacksonMessageBodyProvider altogether, if this would be of interest.