Jackson 3 Migration: Accessing the configured mapper from a custom StdDeserializer

[Kingnaoufal]

Hi,

Subject: Jackson 3 Migration: Accessing the configured mapper from a custom StdDeserializer

While migrating from Jackson 2.x to Jackson 3.x, we ran into a limitation that I am not sure how to handle.

We have a recursive polymorphic model where concrete block implementations are discovered dynamically through plugins. The core application does not know all possible block types at compile time.

With Jackson 2.x, we used a custom StdDeserializer to perform the dispatch. Inside the deserializer, we could retrieve the configured mapper via:

ObjectMapper mapper = (ObjectMapper) jsonParser.getCodec();

And then use that mapper to deserialize nested plugin-provided blocks while preserving all registered modules and configuration.

In Jackson 3.x, this approach no longer seems possible. As a result, we do not have access to the fully configured mapper from within the deserializer.

The obvious alternative would be to inject the ObjectMapper into the deserializer, but that creates a circular dependency:

The ObjectMapper must be built with all modules.
The modules register the custom deserializers.
The deserializers would need a reference to the ObjectMapper.

Therefore, neither side can be constructed first without depending on the other.

Creating a new ObjectMapper inside the deserializer is not an option either because it would not contain the dynamically registered plugin modules and configuration.

What is the recommended Jackson 3 approach for this pattern? Is there a supported way to access the active mapper (or equivalent deserialization context) from within a custom deserializer, or is there a different mechanism that should be used for recursive plugin-based polymorphic deserialization?

[pjfanning]

The fastest way to get answers these days is with Gen AI. And it is faster for you to do that than for me to do it for you.
Claude returns this (on my free plan). I haven't verified everything in the response but it seems like it is along the right track.

Jackson 3.x has an explicit, supported replacement for this pattern — it's just moved from ObjectMapper (via getCodec()) to DeserializationContext. You don't need to inject the mapper at all, which sidesteps the circular dependency entirely.

What changed

In Jackson 3.x, JsonParser no longer carries a back-reference to the owning ObjectMapper. This is intentional — it was removed specifically to eliminate the pattern you're using, in favor of DeserializationContext, which already carries a full, correctly-scoped view of the active DeserializationConfig (including everything registered on the mapper, all modules, all custom deserializers, mixins, features, etc.) for the current deserialization call.

The key point: DeserializationContext is created per invocation, after the mapper is fully built. So a deserializer never needs to hold a reference to the mapper — it just uses the ctxt parameter it's already handed on every deserialize(...) call, and that object always reflects the fully-configured mapper that kicked off the read. This is exactly why it resolves your circular-dependency problem: the deserializer is constructed once (mapper-agnostic), but the context it receives at call-time is always "live" and fully configured.

The mechanism

Instead of:

// Jackson 2.x
ObjectMapper mapper = (ObjectMapper) jsonParser.getCodec();
Block child = mapper.readValue(jsonParser, resolvedPluginType);

use the context to do the nested read:

// Jackson 3.x
@Override
public Block deserialize(JsonParser p, DeserializationContext ctxt) {
    Class<? extends Block> resolvedPluginType = resolveTypeFromPluginRegistry(p, ctxt);
    return ctxt.readValue(p, resolvedPluginType);
}

ctxt.readValue(...) looks up (or builds) the deserializer for resolvedPluginType using the same DeserializerCache/config as the originating mapper — so any plugin-registered modules, custom deserializers, mixins, annotation introspectors, etc. are honored exactly as they would be with mapper.readValue(...).

If you need annotation-aware nested reads for a bean property (rather than a "loose" root-style value), there's also:

ctxt.readPropertyValue(p, beanProperty, resolvedPluginType);

which additionally takes into account contextual annotations on the enclosing property — closer to what happens for normal nested POJO fields.

If you're working off a buffered JsonNode

If your dispatch logic first buffers a subtree as a JsonNode (to peek at a discriminator field before deciding the type) rather than streaming directly, get a parser back out of the tree and feed that into the context:

JsonNode node = ctxt.readTree(p); // or p.readValueAsTree()
Class<? extends Block> type = resolveTypeFromPluginRegistry(node);
try (JsonParser treeParser = node.traverse(ctxt)) {
    treeParser.nextToken();
    return ctxt.readValue(treeParser, type);
}

What stays the same

Your plugin-type-resolution logic (mapping a discriminator string/id to a Class<? extends Block> via your plugin registry) is untouched by this migration — that's your own lookup, separate from Jackson's codec plumbing.

Net effect for your architecture

• No mapper injection needed → no circular dependency.
• No risk of a "naked" ObjectMapper missing plugin modules, because you're never constructing one — you're reusing the context Jackson already built from the real mapper.
• This is the officially recommended approach per Jackson's own migration guidance (confirmed directly by the Jackson maintainer, Tatu Saloranta, in the project's GitHub discussions) — getCodec()-as-mapper-accessor was deliberately removed, with DeserializationContext.readValue/readPropertyValue as its intended replacement for exactly this recursive/composite-deserializer use case.

One caveat worth testing explicitly: make sure your plugin modules register their deserializers on the SimpleModule/JacksonModule mechanism as before — nothing about module registration itself changes, only how a deserializer reaches back into "the mapper's brain" mid-deserialization.