AvroSchema: Does not include base class for records with subclasses

[raphw]

I think I encountered an issue in the schema generation of records that are unions:

jackson-dataformats-binary/avro/src/main/java/com/fasterxml/jackson/dataformat/avro/schema/RecordVisitor.java

Line 53 in 605e79f

for (NamedType subType : subTypes) {

Given the following example (using Jakarta annotations and the introspector that follows with it):

@XmlType(name = "Super")
@XmlAccessType(FIELD)
@XmlSeeAlso(Sub.class)
class Super { 
    @XmlElement(required = true)
    String foo; // getter, setter
}

@XmlType(name = "Sub")
@XmlAccessType(FIELD)
class Sub extends Super { 
    @XmlElement(required = true)
    String bar; // getter, setter
}

where the class Sub is correctly identified, a value of Super is not allowed in the created union.

To avoid this issue, unionSchemas should also include type, if type is non-abstract.

[cowtowncoder]

I think a slightly more extensive example would be useful to show how types in question are used (which specific class is schema being generated etc).
For example, Super here has nothing to link it to Sub (@JsonSubTypes would solve that), but not sure that is what is being problem here.

[raphw]

In my case, I am using Jakarta annotations and the respective introspector (see edit above). But any introspector would do. The problem is that the introspector is requested to return the subclasses and does so correctly:

jackson-dataformats-binary/avro/src/main/java/com/fasterxml/jackson/dataformat/avro/schema/RecordVisitor.java

Line 45 in 605e79f

List<NamedType> subTypes = getProvider().getAnnotationIntrospector().findSubtypes(bean.getClassInfo());

The base class is no longer considered, what is correct if it is abstract. However, a non-abstract class should be considered.

[cowtowncoder]

Ah. Good to know the issue.

@MichalFoksa WDYT? Sounds like it could be an easy fix if you agree this is something to fix.

[MichalFoksa]

Hi there,
I could reproduce the problem and I have ugly fix.
Let me refine it somehow.

[cowtowncoder]

@MichalFoksa sounds good. Depending on whether change is backwards-compatible, can target different branch: if compatible and appears safe, 2.18 (I am thinking of nominating 2.18 as our first ever LTS branch so trying to get safe fixes merged there, get eventually released); if not API compatible or risky, 2.x (for 2.20).