Support for openapi v3/v3.1 schema formats #1291 #1494
Conversation
✅ Deploy Preview for springwolf-ui canceled.
|
| } | ||
|
|
||
| String type = schema.getType(); | ||
| // schema may be an openapi v3 or v3.1 schema. While v3 uses an simple 'type' field, v3.1 supports a set of |
There was a problem hiding this comment.
building examples from types happend to be a little bit 'tricky' because openapi v3 and v3.1 changed the field for the type(s). I moved the "type-lookup" in an extra method 'getTypeForExampleValue'.
| public ExtractedSchemas resolveSchema(Type type, String contentType, SchemaFormat schemaFormat) { | ||
| String actualContentType = | ||
| StringUtils.isBlank(contentType) ? properties.getDocket().getDefaultContentType() : contentType; | ||
|
|
There was a problem hiding this comment.
this is one of the main implementation point: Decision, which ModelConverts to use. AsyncApi is currently based on openapi-V3
| * @return the resulting AsnycApi SchemaObject | ||
| */ | ||
| public SchemaObject mapSchema(Schema value) { | ||
| public ComponentSchema mapSchema(Schema swaggerSchema, SchemaFormat schemaFormat) { |
There was a problem hiding this comment.
This is the point where the generated Swagger-schema (from swagger ModelConverters) is mapped to the target schema format. For openapi v3/v3.1, no transformation is necessary, only wrapping the schema into an MultiFormatschema.
For asyncapi schemaformat (the default), the existing mapping logic is used (mapSwaggerSchemaToAsyncApiSchema
| @JsonSubTypes.Type(value = Dog.class, name = "dog"), | ||
| @JsonSubTypes.Type(value = Cat.class, name = "cat"), | ||
| }) | ||
| @Schema( |
There was a problem hiding this comment.
Extended the Pet Superclass with @Schema Annotation and discriminator mapping Infos. These Infos are ignored for asyncapi schemaformat (because asyncapi does not support custom mappings) - but are detected and used for openapi schema formats.
1 participant
I introduced a new Property
springwolf.docket.payload-schema-formatwhich is an enum and supports currentlyWith the default-setting (asyncapi_v3), SpringWolf behaves as before.
Enabling openapi_v3 or _v3_1 leads to a AsyncApi where the payload schemas (not the header schemas!) are formatted with openapi v3/v3.1 format. This is possible and allowed because the AsyncApi Spec supports the definition of alternative schema formats.
The openapi v3/v3.1 schema formats are especially helpful when it comes to polymorphic schemas with custom discrimiantor mappings (which are not possible to describe with default asyncapi schema format).