Bootstrap ObjectMapper not used in Jersey MessageBodyWriter

[josephlbarnett]

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

[arteam]

It's actualy registered. See here.

Could you provide a test case, when handling Java8 Optional values doesn't work?

[josephlbarnett]

Hmm interesting, if I build a new standalone minimal project, it works properly. Something in our actual application must be conflicting with the default dropwizard provider somehow?

[josephlbarnett]

It appears that adding:

<dependency>
            <groupId>org.glassfish.jersey.media</groupId>
            <artifactId>jersey-media-json-jackson</artifactId>
            <version>2.22.1</version>
</dependency>

as a dependency is what causes this to break

[josephlbarnett]

https://github.com/jbarnettwomply/dropwizard-jersey-media-conflict displays the issue. if the jersey-media-json-jackson dependency is removed, the test passes. alternatively, if the if (false) is changed to if (true) in Java8Application.java in order to manually register a provider, the test passes.

[oillio]

I ran into this problem as well and I think I have tracked down the issue. I am by no means an expert in the internals of Jersey, so this may not be completely accurate.

It looks like jersey-media-json-jackson automatically registers org.glassfish.jersey.jackson.JacksonFeature (via JacksonAutoDiscoverable).

It will register its own FilteringJacksonJaxbJsonProvider which appears to override the dropwizard JacksonMessageBodyProvider.

The new provider doesn't get its object mapper set and uses a default one, ignoring the mapper in the Environment.

First off, you may consider setting the org.glassfish.jersey.internal.InternalProperties.JSON_FEATURE property in Dropwizard. This will ensure this (or any other) JSON feature doesn't stomp on the Dropwizard provider.
You may also want to do what the FilteringJacksonJaxbJsonProvider does and check the JSON_FEATURE property. If it is set to some other value, do not register your own provider. This would have made my life slightly easier.

If you want to support the option of entity filtering in Dropwizard, there doesn't look to be a clean fix. We will need a provider that does both the JsonIgnore stuff currently in Dropwizard's custom provider and the functionality in FilteringJacksonJaxbJsonProvider.

I wrote a workaround to make this work in my project. Maybe it will be helpful to others. It isn't pretty, if anyone has any ideas on a better way to do this, let me know.
https://gist.github.com/oillio/1c1845059caf47527f94202bf14b2dca

I'm happy to write up the JSON_FEATURE functionality described above into a PR, and I can work on a solution to support the entity filtering functionality in DW, if there is interest. Supporting entity filtering will probably require taking a dependency on jersey-media-json-jackson

[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.

[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?)

[lazee]

Thnx @RobeEW ! Really saved my day :)

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days