discriminator field

[fcmdeveloper1]

can we change the specs, so, it can follow the open API specs instead of having discriminator as string

to follow swagger/openAPI 3 to have it like

discriminator: propertyName: type

or is there anything in the APIs let me do this mapping

[github-actions[bot]]

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.

[fcmdeveloper1]

any suggestion or help here

[jonaslagoni]

@fcmdeveloper1 you need to head over to the spec repo for proposing spec changes 🙂

Instead of adapting the AsyncAPI Schema, have you considered just using the OpenAPI schema instead by altering the schema format 🤔?

[Pakisan]

@fcmdeveloper1 you need to head over to the spec repo for proposing spec changes 🙂

Instead of adapting the AsyncAPI Schema, have you considered just using the OpenAPI schema instead by altering the schema format 🤔?

Yep, agree with you.

@fcmdeveloper1

I can't change Schema. discriminator because of it's type, defined on our type: AsyncAPI schemaObject.discriminator

That's why I reject your proposal to change it to OpenAPI schemaObject.discriminator

You can describe your scenario, so we could help you to achieve what you want

[fcmdeveloper1]

thanks @Pakisan for your help and support, my case was that i have some objects has inheritance and i need to use them in Kafka consumer which creates the discriminator as object from the swagger, my case is same like the description in this link https://stackoverflow.com/questions/74474588/publish-multiple-events-shares-some-attributes-in-one-kafka-topic.

i used springwolf, but the generated discriminator doesn't match what asyncAPI is expecting, and i am not sure how to do the required formatting yet.

thanks for your help and support

[Pakisan]

@fcmdeveloper1 hi!

Can you check this response - https://github.com/asyncapi/spec/issues/1037#issuecomment-1967316832?

[fcmdeveloper1]

Hi Pakisan, i think having the "schemaFormat": "application/vnd.aai.asyncapi+json;version=3.0.0", solved it. i used springwolf java api to generate the model, however i believe i have 2 notes (one defect and one as enhancement as mentioned in other comments)

• if there is a child object has a required field, it is not reflected in the UI correctly. (defect)
• the child object should show on the UI all fields direclty (folded), without referencing the parent object as it is mislead the readers. (enhancement)

you can use the below object to test the behavior:

{ "asyncapi": "3.0.0", "info": { "title": "Springwolf example project - Kafka", "version": "1.0.0", "description": "Springwolf example project to demonstrate springwolfs abilities", "contact": { "name": "springwolf", "url": "https://github.com/springwolf/springwolf-core", "email": "example@example.com" }, "license": { "name": "Apache License 2.0" }, "x-generator": "springwolf" }, "defaultContentType": "application/json", "servers": { "kafka": { "host": "192.168.56.107:9092", "protocol": "kafka" } }, "channels": { "example-producer-topic": { "messages": { "com.asyncapi.kafka.dtos.LearningEvent": { "$ref": "#/components/messages/com.asyncapi.kafka.dtos.LearningEvent" } } } }, "components": { "schemas": { "HeadersNotDocumented": { "type": "object", "properties": {}, "description": "There can be headers, but they are not explicitly documented.", "examples": [ {} ] }, "com.asyncapi.kafka.dtos.LearningEvent": { "discriminator": "eventKey", "type": "object", "description": "LMS payload model", "examples": [ { "courseType": "ILT", "eventKey": "string", "eventType": "event Type", "firstName": "mahmoud" } ], "required": [ "courseType" ], "allOf": [ { "$ref": "#/components/schemas/com.asyncapi.kafka.dtos.ParentEventDto" }, { "type": "object", "properties": { "courseType": { "type": "string", "description": "the course type", "examples": [ "ILT" ] } } } ] }, "com.asyncapi.kafka.dtos.ParentEventDto": { "discriminator": "eventKey", "type": "object", "properties": { "eventKey": { "type": "string" }, "eventType": { "type": "string", "description": "this is event type", "examples": [ "event Type" ] }, "firstName": { "type": "string", "description": "the first name of the candidate", "examples": [ "mahmoud" ] } }, "description": "parent Event DTO", "examples": [ { "eventKey": "string", "eventType": "event Type", "firstName": "mahmoud" } ], "required": [ "eventKey" ] } }, "messages": { "com.asyncapi.kafka.dtos.LearningEvent": { "headers": { "$ref": "#/components/schemas/HeadersNotDocumented" }, "payload": { "schemaFormat": "application/vnd.aai.asyncapi+json;version=3.0.0", "schema": { "$ref": "#/components/schemas/com.asyncapi.kafka.dtos.LearningEvent" } }, "name": "com.asyncapi.kafka.dtos.LearningEvent", "title": "LearningEvent", "description": "LMS payload model", "bindings": { "kafka": { "bindingVersion": "0.4.0" } } } } }, "operations": { "example-producer-topic_send_sendMessage": { "action": "send", "channel": { "$ref": "#/channels/example-producer-topic" }, "title": "example-producer-topic_send", "description": "Customer uploaded an example payload", "bindings": { "kafka": { "bindingVersion": "0.4.0" } }, "messages": [ { "$ref": "#/channels/example-producer-topic/messages/com.asyncapi.kafka.dtos.LearningEvent" } ] } } }

My Best Regards

[Pakisan]

@fcmdeveloper1 hi!

Will check it.

Good news, you can checkout branch /release/1.0.0-RC to parse correctly AsyncAPI with OpenAPI and Avro (in few days)

[fcmdeveloper1]

Dear @Pakisan, i think i was wrong to say that it is solved (i tried with springwolf the new version, and i thought that it was solved :( but it seems springwolf did the correct parsing as per AsyncAPI specs ), and i believe that you mentioned it clearly in your previous comment that the "discriminator" is just a simple type, which it is difficult to represent it as the swagger specs which is an object (https://spec.openapis.org/oas/v3.1.0#discriminator-object) that can have its own definition.

so, i believe the APIs like the springwolf and others needs to do the big work to apply these mappings/differences which i believe asyncAPI and openAPI must be unified in a specification to make a standard.

again, i am not sure if a creation of schema definition like this one "application/vnd.oai.openapi;version=3.0.0" can help to unify this or not.

Async API specs: discriminator: eventKey

open API specs discriminator: propertyName: eventKey which has additional mapping option like

discriminator: propertyName: eventKey mapping: ParentEventDto: '#/components/schemas/ParentEventDto' LearningEvent: '#/components/schemas/LearningEvent'

may be we can have additional discussions to figure out a way of this, let me know if i can support.

thanks a lot for your support.

My Best Regards

[github-actions[bot]]

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

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 :heart: