Deserializing into Map<String, Object> based on a map-global type property

[herkrath]

Hi all,

I need to serialize and deserialize a Map<String, Object> containing dynamic properties of different types. As such, there is no Bean-based solution possible. The possible types of properties contain Integers, Doubles, Strings, Enum values, Dates, Times, etc. Due to different constrains, it is not possible to add a type property to every single value, as it is usually done. Instead, there is a map-global property at the same level as the Map, defining a type known to the system. This type defines all possible Map entries and their types.

Example:

{
    "type": "TypeA",
    "values": {
        "Key1": "AString",
        "Key2": "2024-01-24"
    }
    ...
}

... where TypeA defines:

• Key1 as String
• Key2 as LocalDate

The serialization part is trivial, as the Java types are known. However, after trying for very long already, I simply cannot get the deserialization part working:

• I could write a Deserializer for the complete JSON. Then, however, I cannot use all the nice Jackson features for other properties.
• I looked into ways to only handle the values property and delegate the rest to the standard Deserializers. But I couldn't find a way to retrieve the type value while injecting a custom Map Deserializer.
• If I put the Deserializer on values only, I couldn't find a reliable way to retrieve the type value neither.
• Not sure if something like @JsonTypeInfo(use = Id.CUSTOM, include = As.EXTERNAL_PROPERTY, property = "type") may work, but I couldn't get far neither.

Any ideas please?

Thank you so far,
Mark

[cowtowncoder]

This sounds like a very complicate logic so your best bet may well be fully custom deserializer.

[herkrath]

So there is no approved way to access the type value from a deserializer on the Map?

If no, can I somehow delegate from my fully custom deserializer to the standard ones for the remaining properties? Converters are too simple/not applicable, BeanDeserializerModifier seems not well-suiting, I read that extending and delegating to standard Deserializers doesn't work, ...

[cowtowncoder]

Deserializers are only given access to JSON sub-tree to specific to value they are to work on, and need to delegate "down" to values they reference. But there is no access to possible "parent" path (value being constructed -- if one already exists) or "parent" deserializer that called it.

I guess there are 2 types of delegation in existence:

1. Delegation along hierarchy: Map deserializer delegates to Map value deserializers (and KeyDeserializer)
2. Possible delegation "within" value: this is where BeanDeserializerModifier comes in.

Both can be used and are supported. The problem is more in that there is limited interaction between deserializers.

Having said that, JsonParser has method for getting "current value" per nesting level (see JsonParser.getParsingContext()) and that may help in finding parent value (Java Object). Otherwise context gives access to current parsing path (current state, parent states) but not to siblings: there is no full in-memory representation of the input document to access.

Converters might work, but are probably no less work overall than fully custom deserializers (that read full value tree with DeserializationContext.readTree() and operate on that).

[cowtowncoder]

So, in short: to access anything other than specific current token JsonParser points to, deserializer must specifically read full sub-tree and work on that.
And although "currentValue" (which is updated by deserializers) may give you some access, the order in which JSON properties happen to be in document may mean that "type" might not yet be seen in input token stream.

[herkrath]

This is what I already expected based on my experiments. Too bad for me, so no free deserialization of new properties (outside the Map). I got the fully custom deserializer working already though.

But thank you so much for your extraordinary Jackson support! While looking into this issue, I saw you answering so many questions all over the web, and this since years.

[cowtowncoder]

@herkrath Sorry there isn't better way but at least you have been able to work around this so that is good.

And thank you for the kind words! I will try to help people and it is really good to get positive feedback on that, that I am able to make positive difference this way ("non-coding" help). So "thank you for the thank you" :)