fix: parse message payload of any type other than map of String to Object

[yogeshnikam671]

Currently the asyncAPI parser expects the example payload to be an object and hence if it is an array, it does not parse the message associated with such array message.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide 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.

[Pakisan]

@yogeshnikam671 hi!

Let's remember for what MessageExample was introduced. We can use it to show example of message with headers, payload

That's why payload and headers have Map<String, Object> type, to allow users to attach structured examples, like JSON

But here is a clash between MessageExample JSON Schema and MessageExample definition in our docs

It's main reason, why it's take a while to review and analyze proposed change

Right now, I'm figuring out which type is valid and how it can be changed in lib

Will be awesome, if you provide as much of different examples, as it possible

[harikrishnan83]

@Pakisan Thanks a lot for the clarification. Primary we foresee below schema types as payloads.

• Plain old objects
• Array of objects (we often have messages where payload is a list)
• Simple String (which this is not something we encourage, sometimes existing systems do have such cases)

The priority / blocker at the moment is the "Array of objects" use case for which @yogeshnikam671 has added sample spec in this PR and we have also made code changes to achieve this capability.

Kindly review.

cc @yogeshnikam671

[Pakisan]

@harikrishnan83 I'm working on PR to our JSON Schemas and documentation repositories

Yep, looks like payload and headers can be of any type, so 'Object' is a valid type for this fields in class

And they must be validated through schema in Message class

Once I open PR, I'll attach them to this PR

[Pakisan]

lgtm