Missing extensibility point for locating the TypeId

[cdockter]

The current extensibility point for all typing information is TypeDeserializer which has a lot of responsibilities.

I want to implement custom logic to determine the type id for an object even when the type information is not included in the input stream.

In order to accomplish this currently i had to extend AsPropertyTypeDeserializer with deserializeTypedFromArray() and several protected methods overridden.

It would be very useful to have an interface similar to the scope of TypeIdResolver to determine what the type id is for the current object.

This isolation of responsibilities allows for customization of the instance type determination while still leveraging the logic in classes such as AsPropertyTypeDeserializer.

This interface would encapsulate the logic currently implemented in AsArrayTypeDeserializer. _locateTypeId().

The interface method signatures could follow the lines of
public String getTypeId(JsonParser jp, DeserializationContext ctxt)
and
public String getTypeId(JsonParser jp, DeserializationContext ctxt, JavaType defaultType)

[cowtowncoder]

There have been occasional wishes to extend ways in which type id can be determined, for example see #43. Ability to specifically infer type without explicit type discriminator (id) has been mentioned.
The problem so far has been that there is quite a bit of explicit expectation of a single String id; and conversely buffering is only done to support re-creating of token stream after extracting that id.

My feeling is that it probably does not make sense to further expose JsonParser, since that requires explicit buffering and amount of complexity. Rather, it would make sense to allow passing of sub-tree as JsonNode (or TokenBuffer, depending), for cases where streaming (with buffering if need be) is not possible.

I am open to suggestions of how to enable this, but with the limitation that changes can not break existing API, wrt backwards compatibility: existing TypeDeserializer and TypeIdResolver implementations must work as is.

[cowtowncoder]

No clear path on what to do here. This issue may be re-filed, targeting 3.0, with suggestions on possible extension(s).