Extending with custom media types on contract loading

[ppatierno]

We have been using the vertx-web-openapi since years within our Strimzi HTTP bridge component in order to create routes from our own OpenAPI v3 specification JSON file.
We are now in the process to try Vert.x 5.x which is removing such component and replacing it with the vertx-web-openapi-router which uses the vertx-openapi.
The issue we are facing is that in our OpenAPI v3 spec we have custom media types, so something like application/vnd.kafka.v2+json.
In the end this is just JSON (so compatible with the application/json one) but we preferred to have our own custom type.
The issue is that when using the OpenAPIContract.from(vertx, "openapi.json") method we get the following exception:

io.vertx.openapi.contract.OpenAPIContractException: The passed OpenAPI contract contains a feature that is not supported: Operation createConsumer defines a request body with an unsupported media type. Supported: application/json, application/json; charset=utf-8, multipart/form-data, application/hal json

The exception itself is pretty clear even looking at the code and how the vertx-openapi works by supporting a limited list of media-types.
My question is what's the way to overcome this problem by adding a custom media type and avoid such an error? I can't find any information about how much this is pluggable without changing the openapi.json file and moving to use application/json.

Within this repo (in the index.adoc file) I read the following:

NOTE: It is planned to support more media types in the future.
It is also planned to support custom implementations of {@link io.vertx.openapi.validation.analyser.ContentAnalyser}, so that any media type can be validated.

[pk-work]

Hi @ppatierno thanks for using Vert.x OpenAPI! Yes, at the moment this is a limitation which affects a lot of users. Solving this issue is one of my highest priorities. I need to figure out a good way to support custom implementations of ContentAnalyser. Unfortunately since a few weeks / months my time I can spent on this is very limited.

If you have time to work on a fix for this I would appreciate it. If so, we should briefly discuss the planned idea. It would be bad to spend implementation effort on a solution that may not fit into the library.

Otherwise you just have to wait a little bit longer :)

[pk-work]

duplicate #18