Give Custom Deserializers access to the resolved target Class of the currently deserialized object

[Laures]

Jackson resolves the target class for a json object using parameter/property types, annotations, json properties or a parameter in the object mapper.

please give custom deserializers easy access to this information. currently it is nearly impossible to create a deserializer that works for multiple types. the only way would be to implement "contextualdeserializer" and access the bean property which is very complicated.

[cowtowncoder]

Can you suggest a way in which it would make sense to pass this information? Keep in mind that deserializers are stateless objects, so this information would need to be passed in context somehow; and should not incur significant additional overhead for cases where it is not needed.

Another way of putting my question is whether this would be during construction of deserializer (and it being cached), or during operation. Jackson tries to put as much work as possible on former part, FWIW.

[Laures]

i would suggest an interface similar to the ContextualDeserializer that a deserializer/serializer can implement and return a properly configured instance.

[cowtowncoder]

So something like "TypeSpecificDeserializer" add-on interface? So compared to ContextualDeserializer, type for which deserializer is being built would be explicitly passed (and in case of root values, it wouldn't even be available).

I also assume this should be resolved before ContextualDeserializer, so type-specific specialization would take place first, and then one could also implement ContextualDeserializer if that makes sense.
Further, this resolution could be done before caching and only be done once per type, whereas ContextualDeserializer is called once per property.

I think that could work...

[cowtowncoder]

Oh, one more question -- wouldn't it be possible to configure this on your end when adding custom deserializers? Although SimpleModule only supports dumb registration by specific type, underlying Deserializers (and matching Serializers) interfaces pass in specific type for which deserializer is being used. So why does this not work?

[Laures]

could you elaborate how they do that? afaik a deserialize call does not contain type information.

[cowtowncoder]

I meant com.fasterxml.jackson.databind.deser .Deserializers (note the 's') abstraction that gets the callback to construct a new JsonDeserializer, "findBeanDeserializer(...)".
Not during deserialization itself (that information is not pass and deserializer is expected to have retained it from construction).

[Laures]

Ah. That works fine for (de)serializers that handle a specific type. but what about (de)serializers that handle a specific property, maybe of an (for them) unknown type? the type has to be known to jackson at (de)serialization but there is no way for such a (de)serializer to know it. over the last weeks i had several such cases. it is possible to work around that with the contextual(de)serializer interface. but that workaround misses information and therefor can fail in special scenarios.

[cowtowncoder]

That's not how Jackson deserializers work -- they are bound to specific types. You can of course register single (de)serializer for all kinds of types, but if so, you will have to deal pass through the type and contextual information as it becomes available, creating distinct deserializer instances with that information (as necessary). So you sort of need to build more distinct instances incrementally, such that deserializer will know what kind of type it will be dealing with as part of construction process. This information will not be passed during actual deserialization calls, except (to limited degree) for polymorphic deserialization in which case TypeDeserializer helper object will coordinate use of type information (to once again find type-specific actual JsonDeserializer).

[Laures]

So you sort of need to build more distinct instances incrementally, such that deserializer will know what kind of type it will be dealing with as part of construction process.

i would do that, but the resolved property type is not available in a contextual way.

[cowtowncoder]

I may have misunderstood your use case. So let me go back to basic question: how is your deserializer registered?

So far I assume you are registering them via Module interface, in which case type would definitely be available through process.
But there is then the other way to register (de)serializers: with direct annotation on property. In this case there is no callback to provide type as instance is simply constructed.
Is this the way deserializers in this case are constructed? If so, I see the problem.

[Laures]

thats exactly right. the deserializer is used for a property of the type List<T>. Jackson knows what T is during deserialization (either because it was annotated or because mapper.readValue(....) containt the type information. To properly deserialize the property i need that info.

currently i just use the ContextualDeserializer interface and look up the type from the BeanProperty. but the moment somebody does something fancy (interfaces, ....) i expect this to fail.

[cowtowncoder]

Just one more clarification: is this used with something like:

@JsonDeserialize(contentUsing=MyValueSerializer.class)
public List<MyValue> values;

or by registering MyValueSerializer via Module API?

If latter, it still does not explain why you think type is not available. List (array, Map) deserializers do not handle value instances themselves, but delegate to value deserializers, and these are constructed and initialized like any other deserializers, including passing of type information.

Apologies for tons of questions -- I just want to make sure I fully understand problem being solved. At this point Jackson API is big (and thick) enough that I am trying to limit number of additions. I do agree in that type information would be good to pass, and if Contextual(De)Serializer was not an interface, I would add it there. But alas it is not... And additions then need to pass more checks due to need for bigger changes to support them.

[Laures]

its the annotation.

[cowtowncoder]

Ok thanks. The request then makes sense.

Another way to handle this would be to bite the bullet and consider addition of (de)serializer factory/builder annotation. This would allow passing as much context as necessary, and would be easy to extend.