test: Add test showing how @JsonSubTypes can be used with @Schema-oneOf annotations

[Mattias-Sehlstedt]

Description

TL;DR: I have introduced a test showing how one can circumvent the fact that a @JsonSubtypes will always produce an allOf polymorphic structure (that also breaks if a oneOf @Schema is specified at the same time). This is a reoccurring questions I get, so I would like to collect the solution in a location where it can have two purposes (showing the behavior of the ModelResolver, but also at the same time being a reference that I can share for how to adjust for the scenario).

---

I have many times had discussions regarding how polymorphic models can be constructed/expressed when exposing an OpenApi specification by using springdoc (which relies on swagger-core). Some examples being springdoc/springdoc-openapi#3054 and springdoc/springdoc-openapi#3103.

The scenario is that @JsonSubtypes has to be used to guide Jackson in the deserialization process, but the specification provider prefers to expose the polymorphism with a oneOf structure rather than a allOf structure. My current understanding is that this can be realized by having the parent class own the @JsonSubTypes, while it also implements an interface carrying a @Schema annotation containing a oneOf definition.

My preferred solution would be that it should be configurable whether the @JsonSubTypes is processed (I.e., an explicit @Schema annotation should take precedence over it). I know that this can be realized by providing a custom ModelResolver, but given its current size it is cumbersome to override it. I would have preferred if the ModelResolver had an isolated method responsible for it, so I could just define a ModelResolver that overrides only that method.

I understand that this is a difficult thing to achieve, so thus I elect to add illustrative tests to show the current behavior before I attempt anything. This since it is helpful to add tests for common use-cases even if I do not even introduce any change in behavior with a later PR.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

Screenshots / Additional Context