Why is @JsonTypeResolver separate from @JsonTypeInfo ?

[bytesandwich]

It seems in JacksonAnnotationIntrospector that @JsonTypeResolver cannot exist without @JsonTypeInfo

protected TypeResolverBuilder<?> _findTypeResolver(MapperConfig<?> config,
            Annotated ann, JavaType baseType)
    {
...
JsonTypeInfo info = ann.getAnnotation(JsonTypeInfo.class);
JsonTypeResolver resAnn = ann.getAnnotation(JsonTypeResolver.class);
if (resAnn != null) {
            if (info == null) {
                return null;
            }

Unless I misunderstood this, I think it is unnecessary and confusing.

[cowtowncoder]

I am not sure I see what the use case would be without dependency, as type resolvers are only used in context of polymorphic type handling, which is enabled by use of @JsonTypeInfo (with exception of "default typing").
So what would you want to do with stand-alone type resolvers?

[bytesandwich]

Sorry for not explaining very well. When I read the javadoc, I thought typeResolver would generally be able to handle type information. Basically I thought it would should have the functionality required for #43. I was surprised when I looked at the unit tests and found that it relies on typeinfo.

As it does not exist without jsontypeinfo, I would think it logical to have an additional field in type info, and maybe rename type info, rather than adding this dependent second annotation. That way, the annotation encapsulates a logically complete unit of metadata.

I was thinking that if I use include Id.NONE then register a typeResolver to inspect the bean, I could get what I want. You suggested that TypeResolver wasn't intended for this purpose, but I think it would be more intuitive to restructure these two annotations, particularly if things are being uprooted for #43.

[cowtowncoder]

Ok, yes, I can see how this would appear starting from javadocs, esp. as it is not clear that pieces (must) work together.
At this point the interaction between pieces can not be radically changed (... at least not before Jackson 3....), for better or worse. Type id handling is only enabled when it is specifically enabled (mostly to reduce overhead of both additional info to include and more importantly processing overhead).

But things can of course be improved. I think the best way to go about it is to figure out desired functionality, and see how pieces need to be enhanced to support that. TypeIdResolver is speficifically greated to support existing type-id-String use case.

[bytesandwich]

I was thinking about it and I think the best thing to do would be to have JsonTypeResolver just become a method inside JsonTypeInfo, if the hierarchy doesn't change.

[cowtowncoder]

I don't thing we should change this interaction without specific reasons, as backwards compatibility with existing customizations is very important. Closing this for now; can re-open if revisiting is needed.