Expose Jackson.configure method

[socram8888]

Problem:

Up until now, I were using the ObjectMapper.enable(MapperFeature) call to enable the PROPAGATE_TRANSIENT_MARKER feature, so transient properties in non-Jackson-aware code get skipped in the resulting JSON.

I'd set this property in the initialize method like so:

@Override
public void initialize(Bootstrap<T> bootstrap) {
	bootstrap.getObjectMapper().enable(MapperFeature.PROPAGATE_TRANSIENT_MARKER);
}

Since version 2.13 however, this method has been marked as deprecated, which means it might get removed in a future version, making this approach a non-ideal one.

The deprecation node says to use a JsonMapper.Builder, set the relevant flags, then build the ObjectMapper.

However, the problem is that Dropwizard does not expose the configure method in its Jackson class, which makes it impossible to create an ObjectMapper with this flag set, and install easily all Dropwizard-provided modules without having to copy and paste said code.

Solution:

This PR makes said method public, so one can configure arbitrary ObjectMappers with Dropwizard's default set of mappers and settings.

public void initialize(Bootstrap<T> bootstrap) {
	JsonMapper mapper = JsonMapper.builder()
			.enable(MapperFeature.PROPAGATE_TRANSIENT_MARKER)
			.build();
	Jackson.configure(mapper);
	bootstrap.setObjectMapper(mapper);
}

[zUniQueX]

Hi @socram8888. Thanks for your contribution!

I wonder, if some methods to enable/disable features get deprecated now, if the others will also in future versions. Should we rewrite the Jackson class to configure the ObjectMapper with a builder? Then the configure method would get the builder as the parameter. This should be discussed before we add this method to the public API.

[socram8888]

If the idea that Jackson developers is going towards an immutable ObjectMapper, which seems to be the case, I think it'd make sense.

If we use that JsonMapper.Builder, one option to fix this issue would be a good idea to allow accessing to said JsonMapper.Builder in the initialize method of the Application class, instead of the somewhat-immutable ObjectMapper, so it can be easily configured before the application starts. It'd be a breaking change though.

An less radical option would be to update the Jackson class to use the builder, and still make the method public as in this PR, but taking a builder instead.

EDIT: Can confirm immutable ObjectBuilders seem to be the way to go: https://fasterxml.github.io/jackson-databind/javadoc/2.13/com/fasterxml/jackson/databind/cfg/MapperBuilder.html#addModule-com.fasterxml.jackson.databind.Module-

Jackson 3 will introduce fully immutable, builder-based system for constructing ObjectMappers. Same can not be done with 2.10 for backwards-compatibility reasons; but we can offer sort of "fake" builder, which simply encapsulates configuration calls. The main (and only) point is to allow gradual upgrade.

[zUniQueX]

Hi @socram8888. Thanks for looking this up.

When Jackson will prefer the builders, we should upgrade to them, if possible. If this implies a breaking change, we can release it with the Jakarta EE 10 upgrade in Dropwizard 5.x.

[zUniQueX]

Hi @socram8888. The branch for Dropwizard 5.x is open, but I'd like to postpone this change until Jackson 3 gets released to integrate the new immutable APIs. Are you fine with that?

[socram8888]

Hi @socram8888. The branch for Dropwizard 5.x is open, but I'd like to postpone this change until Jackson 3 gets released to integrate the new immutable APIs. Are you fine with that?

I'm not in a hurry - since it still works, I ended up adding deprecation warning ignores and called it a day.