case I had in mind was when you only deserialize a subpart of the tree and
not the root directly. At each level you can prevent to re-enter in the
same deserializer but you can need it later in the tree.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2016-05-10 16:02 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>:
> Is there a usecase where you actually may need reentrant deserialize()
> calls, with recursive models?
>
> When you call context.deserialize() inside deserializer, even for other
> type than deserializer return type, you may still encounter deserialization
> into return type of deserializer inside.
>
> Roman
>
>
> On 05/10/2016 03:49 PM, Romain Manni-Bucau wrote:
>
> Hi Roman,
>
> We encountered it in johnzon when Mark implemented it. We chose to just
> prevent these loops since they can easily be detected at framework level
> but not expose it to the end user.
>
> typically in your code it would be:
>
> ctx.deserialize(clazz, parser) { // pseudo code
>
> return this.deserialize(clazz, parser, <ignore PolymorphicDeserializer for root level *only*>);
>
> }
>
> Note: in this snippet it would be great to not require the hasNext to be called (ie if called ok but if not then deserialize can do it).
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
> 2016-05-10 15:42 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>:
>
>> According to polymorphic deserialization, which was one of the usecases
>> for deserializers, I encountered the fact, that if context.deserialize() is
>> called inside the deserializer for the type that is the return type for
>> that deserializer, jsonb runtime will try to use such deserializer again
>> inside. Example:
>>
>> public class PolymorphicDeserializer implements JsonbDeserializer<Animal> {
>> @Override public Animal deserialize(JsonParser parser, DeserializationContext ctx, Type rtType) {
>> Class<? extends Animal> clazz = null;
>>
>> while (parser.hasNext()) { //some code to get class, which will result to subclass of an Animal //... //following will cause adding PolymorphicDeserializer instance to call stack again, calling deserialize on it
>> return ctx.deserialize(clazz, parser); //--- REENTRANT CALL---
>> }
>> throw new IllegalStateException("animal not found!");
>> }
>> }
>>
>> Looks like this is correct behaviour, JSONB runtime has deserializer
>> registered for it. Without some kind of parameter flag it has no clue not
>> to use it. How about adding default to true method "boolean isReentrant()"
>> to JsonbDeserializer interface?
>>
>> Thanks,
>> Roman
>>
>
>
>