AsyncAPIInputProcessor does not respect schemaFormat of the message

[mschroeger-interhyp]

Describe the bug.

Hi modelina community,

I recently started trying out asyncapi documents and in the course of this also the modelina generator in my company.
Since reusing the openapi schemas is one of the biggest advantages for me here, I encountered the following problem:

Using this valid openapi 3 schema definition including a discriminator in an asyncapi 2.6 document

messages: {
  Vehicle: {
    schemaFormat: 'application/vnd.oai.openapi;version=3.0.0',
    payload: {
      type: 'object',
      title: 'Vehicle',
      discriminator: {
        propertyName: 'vehicleType',
        mapping: {
          car: '#/components/schemas/Car',
          truck: '#/components/schemas/Truck'
        }
      },
      oneOf: [
        { $ref: '#/components/schemas/Car' },
        { $ref: '#/components/schemas/Truck' }
      ]
    }
  }
}

and generating java code with jackson_preset results in the following output which obviously can not be deserialised

@JsonTypeInfo(use=JsonTypeInfo.Id.NAME, include=JsonTypeInfo.As.EXISTING_PROPERTY, property="[object Object]", visible=true)
@JsonSubTypes({
  @JsonSubTypes.Type(value = Car.class, name = "Car"),
  @JsonSubTypes.Type(value = Truck.class, name = "Truck")
})
/**
 * Vehicle represents a union of types: Car, Truck
 */
public interface Vehicle {
  
}

After having a deeper look into the source code I saw that the AsyncAPIInputProcessor always treats the payload of the message as an AsyncapiV2Schema. There, the discriminator property is of course a string, and not an object as in openapi.

The given schemaFormat "application/vnd.oai.openapi;version=3.0.0" is never evaluated. According to the modelina docs, it should:
We support the following AsyncAPI versions: 2.0.0 -> 2.6.0, which generates models for all the defined message payloads. It supports the following schemaFormats AsyncAPI Schema object, JSON Schema draft 7, AVRO 1.9, RAML 1.0 data type, and OpenAPI 3.0 Schema.

As I am quite new to the asyncapi world, I may have completely overlooked or misunderstood something. I would be happy to receive feedback!

Expected behavior

Output should be:

@JsonTypeInfo(use=JsonTypeInfo.Id.NAME, include=JsonTypeInfo.As.EXISTING_PROPERTY, property="vehicleType", visible=true)
@JsonSubTypes({
  @JsonSubTypes.Type(value = Car.class, name = "Car"),
  @JsonSubTypes.Type(value = Car.class, name = "car"),
  @JsonSubTypes.Type(value = Truck.class, name = "Truck"),
  @JsonSubTypes.Type(value = Truck.class, name = "truck")
})
/**
 * Vehicle represents a union of types: Car, Truck
 */
public interface Vehicle {
  String getVehicleType();
}

Screenshots

How to Reproduce

1. Take a valid openapi schema as message payload like above
2. Generate java code using JAVA_JACKSON_PRESET

const generator = new JavaGenerator({
  presets: [JAVA_JACKSON_PRESET],
  processorOptions: {
    interpreter: {
      allowInheritance: true
    }
  }
});

.

🥦 Browser

None

👀 Have you checked for similar open issues?

• I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue ?

None

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[jonaslagoni]

So this issue is two parts.

1. The OpenAPI input processor does NOT recognize the discriminator value in the OpenAPI Schema.
2. The AsyncAPI input processor does not "pass on" the schemas to the different input processors, but instead, the AsyncAPI schema parsers are used.

@kennethaasan do you have an overview of how easy it is to reuse the discriminator value in AsyncAPI Schema object and in the common model to enable it for OpenAPI schemas? 🤔

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️