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
>