Re: [jsonb-dev] Custom deserialize array property

[Michael Lipp <mnl@xxxxxx>]

Am 23.10.24 um 13:04 schrieb Romain Manni-Bucau:

Hi Michael,

We got this issue as well in Johnzon and worked around the JSON-B layer cause this is not practicable (deserializers are not reusable and you must implement one per location - array, property, ...).

I would be in favor of fixing JSON-B deserialization model - with a JsonbConfig toggle for backward compatibility and short term you implement a dedicated deserializer for the full array?

I don't see how this could help. In my implementation, I still couldn't use the DeserializationContext for deserializing the elements of the array. So I'd have to re-implement my own deserializers for all types (possibly) used as elements.

Speaking of Johnzon, the crude workaround is to simply ignore the Javadoc. I've tried it and you can invoke the deserialize method when the parser is positioned on the START_ARRAY (or the last token of something deserialized before). Eventually, after the last element, the deserialize will see the END_ARRAY (without knowing about the START_ARRAY) and return an empty array that I can use to terminate my loop. But this is nothing but an unreliable hack, of course.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Le mer. 23 oct. 2024 à 12:55, Michael Lipp via jsonb-dev <jsonb-dev@xxxxxxxxxxx> a écrit :

Hello,

if this is the wrong place for this topic, I apologize in advance.
However, I couldn't find or think of anything better place.

I'm trying to port a deserializer from Jackson to Json-B. The Json to
deserialize looks like this (simplified):

{

     "prop1": "something",

     "prop2": [ "something else", 42, { "attribute": "value" } ]

}

In addition, there is a Java type "class Something { public String
attribute; }" that should be used for entry 2 in the array in the result
of the deserialization (actually, the class is more complex).

When deserializing this, I know (from the "rtType" passed to the
"deserialize" method of my deserializer) the Java types of the elements
in the array in "prop2". Therefore, I don't want to forward the
deserialization of the array to the DeserializationContext because it
does not know about the types used in the array and would use a Map for
the last element. I want to do it myself.

This is no problem with Jackson, because its equivalent to
DeserializationContext expects the parser to be positioned on the start
token of the item to deserialize. I therefore consume the START_ARRAY,
get the next token, check if it is END_ARRAY, and if it is not, I make
Jackson deserialize the next (actually current) item with the expected
Java type.

The Json-B apidoc for DeserializationContext#deserialize states that
"JsonParser cursor have to be at KEY_NAME before START_OBJECT /
START_ARRAY, or at START_OBJECT / START_ARRAY to call this method." But
I cannot leave the cursor at "prop2", because then the
DeserializationContext deserializes using default types. Of course, I
could post-process the result created with default mappings and adapt it
to my expected type. But this requires additional coding and additional
CPU cycles at run-time.

Is there any solution to this problem that I have missed or is this
simply a use case that wasn't considered when specifying Json-B?

  -  Michael


_______________________________________________
jsonb-dev mailing list
jsonb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jsonb-dev