Deserialization of `@JsonTypeInfo` annotated type fails with missing type id even for explicit concrete subtypes
See original GitHub issueWhen attempting to deserialize to a concrete class that is part of a polymorphic type hierarchy, an InvalidTypeIdException is thrown if the JSON does not contain the type id field. Example:
@JsonTypeInfo(
use = JsonTypeInfo.Id.NAME,
property = "type")
@JsonSubTypes({
@JsonSubTypes.Type(value = Foo.class, name = "foo"),
@JsonSubTypes.Type(value = Bar.class, name = "bar")})
public interface Base {}
public class Foo implements Base {}
public class Bar implements Base {}
ObjectMapper mapper = new ObjectMapper();
mapper.readerFor(Foo.class).readValue("{}"); // throws InvalidTypeIdException
mapper.readValue("{}", Foo.class); // throws InvalidTypeIdException
While I understand why this happens, as Jackson is finding the JsonTypeInfo / JsonSubTypes annotations on the interface, it is counterintuitive to me. In this instance, I am instructing the mapper as to the specific concrete class to deserialize to, so consulting those annotations seems unnecessary. Perhaps checking if the class / type supplied to readerFor / readValue matches exactly one of the classes listed in JsonSubType could be a fallback if the type id property is not found?
So far, the only workaround I’ve found is to do something like this:
@JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
public class Foo implements Base {}
but then that means serializing a Foo instance would not get the type id property. Perhaps a custom TypeIdResolver or SubTypeResolver could also be used, but having the described behavior baked in seems like a sensible default to me. Thoughts?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:11
- Comments:9 (4 by maintainers)
Top GitHub Comments
Here’s an example. We have a tool that generates Java / Kotlin classes from GraphQL schemas, so given an example trivial schema:
We might generate the following for the Animal interface so that query for animals works correctly:
Now when queries are also built using our codegen tool, we can always arrange for the
__typename
meta field to be returned, but some users may opt to only use the generated types and build their own queries by hand. To us the generated class even when querying for a specific type likeDog
, they need to remember to also always ask for__typename
, which seems a little strange to have to do if they are indicating at time of deserialization they know the concrete type based on the query they’re performing.I can also think of non-GraphQL scenarios, where the client is using generated code and doing similar queries for REST endpoints like /animals, /dogs, and the server component is perhaps not using the same classes at all or is written in a different language. Yes, the /dogs endpoint could return JSON with type ids, but it seems redundant to have to do that when the client is specifically asking for a “concrete type” in this case.
I would also find this feature very useful.
I want to share a workaround which seems to work fine in my case: to annotate the subclasses with the same
@JsonTypeInfo
, but including adefaultImpl
. For instance:It is not exactly pretty, but it seems to be working as expected.