Work-around for #1565: Deserialization failure with Polymorphism using JsonTypeInfo defaultImpl

[slobo-showbie]

This commit provides a work-around-ish solution for #1565. It does not attempt to address the deeper issues as discussed in #1358.

Basically this patch adds a check to detect the scenario when defaultImpl is set to a class that is not a subclass of the base type: Then in that case, check whether baseType and defaultImpl share a superclass with the @JsonTypeInfo annotation. If yes, allow the type deserializer to be built without defaultImpl. If no, then the current behaviour applies (exception thrown because of invalid @JsonTypeInfo).

[cowtowncoder]

Hmmh. So, this patch seems to quietly swallow indications of possible problem, allowing use cases where it makes sense to pass.
My concern here is that doing this will also remove sanity check that should apply to usage: there are cases where exception should be thrown.
Or does code handle this case, but trying to guess whether there has been valid usage somewhere along shared ancestry types (I'll have another look at code).

Fundamentally I think a better solution would be to retain information on where particular annotation was added, so that polymorphic handling definitions would only apply if added at nominal base type (put another way: definition would not be inherited by subtypes).

So I'll have to think about this one.

[slobo-showbie]

I agree that the better solution is to keep the source of the annotation around. However, this patch is intending to address the issue until the better solution can be put into place.

The latest commits tighten the checks a bit. As far as I know the invalid case it lets through is when there are multiple @JsonTypeInfo annotations in the hierarchy of the particular subtype that baseType is set to.

[cowtowncoder]

Ok. Yes, I re-read this, and agree that from functionality perspective introspection makes sense.
From implementation perspective it has to do things like direct lookup of annotations (which should not be done -- all access via AnnotationIntrospector), and would have hefty introspection overhead (doubling processing due to construction of AnnotatedClass).
So I think that I am leaning towards fewer checks altogether for 2.x, and deferring proper solution for 3.x, where we can retain information to implement checks in better way.

Thank you for the patch: it has helped a lot, even if I don't use it as-is.