Skip to content

Conversation

@tvahrst
Copy link
Contributor

@tvahrst tvahrst commented Nov 2, 2025

I introduced a new Property springwolf.docket.payload-schema-format which is an enum and supports currently

  • asyncapi_v3 (the default)
  • openapi_v3
  • openapi_v3_1

With 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).

@netlify
Copy link

netlify bot commented Nov 2, 2025

Deploy Preview for springwolf-ui canceled.

Name Link
🔨 Latest commit 14961f0
🔍 Latest deploy log https://app.netlify.com/projects/springwolf-ui/deploys/6920a7263924100008a9fe62

@sam0r040 sam0r040 force-pushed the componentschema-refactoring branch from d8d540e to ad80cfa Compare November 7, 2025 15:35
Copy link
Member

@timonback timonback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam0r040 and I reviewed the PR. We enjoyed the PR very much. The PR is surprisingly sleek and it shows that you have understood and found the best place for integrating this feature.

We added some comments, suggestions. If there are questions, let us know. Some comments probably also reflect the Springwolf code style.
FYI: We committed & pushed a couple smaller changes (i.e. avoiding breaking API change)

@sam0r040 sam0r040 force-pushed the componentschema-refactoring branch from 23e6862 to 98a085c Compare November 7, 2025 17:12
…chema, change back public api method from registerSimpleSchema to registerSchema to prevent breaking change, rename SwaggerSchemaService.postProcessSimpleSchema to postProcessSchemaWithoutRef to clarify the intention of the method

Co-authored-by: Timon Back <[email protected]>
@sam0r040 sam0r040 force-pushed the componentschema-refactoring branch from 98a085c to f3b6093 Compare November 7, 2025 17:25
Copy link
Member

@timonback timonback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started looking at the output openapiv3 file it is looks quite similar. Besides that the json-schema extension is not really supported, the rest looks fine or related to the difference between openapi 3.0 vs 3.1

Testing:
-> remove runtimeOnly project(":springwolf-add-ons:springwolf-json-schema")
-> add @JsonPropertyOrder(alphabetic = true) to SchemaObject for easier comparison


One more question, when using the payloadSchemaFormat, why not also format the header schemas using the same setting?
Does your use-case only require the payloads in one format and the headers in the default?
I would have assumed that if I change it, all schema change.

@tvahrst
Copy link
Contributor Author

tvahrst commented Nov 15, 2025

Yes, Asyncapi and OpenAPI schema formats are quite similar. The main difference lies in the area of ​​inheritance. Schema classes with defined discriminator fields and values ​​are not (well) implemented by Asyncapi. That was the original motivation for this pull request.

The main reason for not using the payload schema format for the headers was that the headers are usually so simple that there are no differences between AsyncAPI and OpenAPI.

I thought it would unnecessarily bloat the resulting AsyncAPI by turning every headers block into a MultiSchemaFormat header:

headers:
  type: object
  properties:
    my-header-1:
      type: string
      description: Header 1
    my-header-2:
      type: string
      description: Header 2

to

headers:
  schemaFormat: application/vnd.oai.openapi;version=3.0.0
  schema:
    type: object
    properties:
      my-header-1:
        type: string
        description: Header 1
      my-header-2:
        type: string
        description: Header 2

But I must admit that the overhead is not that large at all. So - It might simplify the implementation if the schemaformat is used globally for payload and headers.

I would try change the PR towards a global asyncapi schemaformat. What do you think is a good propertyname / Enum classname instead of 'PayloadSchemaFormat'? Simply 'SchemaFormat' (which already exists), 'AsyncApiSchemaFormt' oder 'OutputSchemaFormat' ?

@timonback
Copy link
Member

timonback commented Nov 16, 2025

Sounds good. Since it is the configuration for schemaFormat, it can also be called SchemaFormat. If that is confusing with the asyncapi one, maybe SchemaFormatConfig?

I am mostly concerned about complexity and maintainability in the long term. We are a small team, so the easier it is now (also to contribute) the more features and less bugs are shipped.

A bloated document can be improved later as an optimisation, possibly also via a serialiser.

(Actually, I was considering if it is easier, when internally everything is a MultiFormatSchema and therefore less checking if this else that)

sam0r040 and others added 2 commits November 21, 2025 18:48
…t directly from global configuration

Co-authored-by: Timon Back <[email protected]>
@sam0r040 sam0r040 merged commit 100caee into springwolf:master Nov 21, 2025
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants