Polymorphic deserialization should handle case-insensitive Type Id property name if `MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES` is enabled

[soundvibe]

Consider this data class:

@JsonTypeInfo(use=JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.EXTERNAL_PROPERTY, property = "operation")
@JsonSubTypes({
        @JsonSubTypes.Type(value = Equal.class, name = "eq"),
        @JsonSubTypes.Type(value = NotEqual.class, name = "noteq"),
})
public abstract class Filter {
    public String operation;
}

MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES is enabled for ObjectMapper:
objectMapper.enable(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES);

Trying to deserialize json { "operation": "EQ"} fails with:
com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could not resolve type id 'eq' into a subtype of...

but deserializing from { "operation": "eq" } works as expected.

It would be great if MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES would also work for this use case.

Tested with Jackson 2.8.0.

[cowtowncoder]

Hmmh. Interesting. Yes, I think it would make sense. Thank you for reporting this.

[asambol]

The same should be taken into account for actual property upper/lower case. In this example, both "operation" and "Operation" should be successfully deserialised. Currently, it doesn't work - we have to choose one.

[cowtowncoder]

@asambol if MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES is enabled (globally, or as one of features of per-property @JsonFormat), that's how it should work. Is that not the case for you?

[asambol]

@cowtowncoder It's currently not the case. The following code works for lowercase "type" property, but not for "Type". I'm getting mixed case from an API and basically have to choose between uppercase and lowercase + ignoring exceptions for the other.

@JsonTypeInfo(
    use = Id.NAME,
    include = As.PROPERTY,
    property = "type"
)

[cowtowncoder]

@asambol ah! I see what you mean. Did not read it carefully.

In fact, I think that (virtual) property name should match, but actual type id not necessarily -- that's not what feature actually controls.

At the same type I can see why accepting case-insensitive Type Id value could be useful: I am just not sure how the API should work: I do not like overloading or arbitrarily existing definitions. Type id value is not a property (name).

[cowtowncoder]

Note to possible contributors: the good first step would be to add a failing unit test under failing package (so it will not block builds). I can also help anyone who wants to know where handling of Type Id occurs.

If anyone is thinking of tackling this, just add a note here: I am not working on this, and will not do if someone else is. I may eventually have another look if no one works on it, but right now there are many other open issues for me to focus on.

[alevskyi]

I would like to pick this task

[cowtowncoder]

@alevskyi That would be great! I think that this should go in 2.11 branch so may make sense to branch from 2.11 (I can handle merging into master)