Spring generates duplicated JsonSubTypes
Hello everyone,
When I use the openapi-generator with a discriminator and mapping, it generates two @JsonSubTypes
discriminator:
propertyName: type
mapping:
foo: "#components/schemas/Foo"
Generates something like this
@JsonSubTypes.Type(value = Foo.class, name = "Foo")
@JsonSubTypes.Type(value = Foo.class, name = "foo")
Notice the duplication. The Foo is the class name of the class, and the lowercase foo is my mapping. Wtf is going on lol. This doesn't seem right.
The Foo class is defined something like
Foo:
allOf:
- $ref: "#components/schemas/someParent"
- type: object
properties:
type:
type: string
I am using version 6.0.1 and the schema version is openapi: '3.0.0'
Here's the full spec to generate the incorrect thing:
openapi: '3.0.0'
info:
version: '1.0.0'
title: 'FooService'
paths:
/parent:
put:
summary: put parent
operationId: putParent
parameters:
- name: name
in: path
required: true
description: Name of the account being updated.
schema:
type: string
requestBody:
description: The updated account definition to save.
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/Parent'
responses:
'200':
$ref: '#/components/responses/Parent'
components:
schemas:
Parent:
type: object
description: Defines an account by name.
properties:
name:
type: string
description: The account name.
type:
type: string
description: The account type discriminator.
required:
- name
- type
discriminator:
propertyName: type
mapping:
foo: '#/components/schemas/Foo'
Foo:
allOf:
- $ref: "#/components/schemas/Parent"
- type: object
properties:
fooType:
type: string
responses:
Parent:
description: The saved account definition.
content:
application/json:
schema:
$ref: '#/components/schemas/Parent'
I generated this by running
java -jar openapi-generator-cli.jar generate -i schema.yaml -o foo -g spring
I also came across this bug using 6.0.0.
As a temporary workaround I renamed the schema to start with lower case (foo) in the api-doc, since it was breaking deserialization on the remote.
Hi! This bug also prevents me from updating from 5.4.0 to 6.1.0
For me, this is also a problem. We make heavy use of inheritance and Jackson will serialize the values incorrect. The type value is now Foo instead foo, which is not even part of my discriminator options: { "type": "Foo" }
Same problem for me, event with version 6.2.0 of the openapi-generator-maven-plugin
if you add an x-discriminator-value to the components you can even force a third one:
Foo:
allOf:
- $ref: "#/components/schemas/Parent"
- type: object
properties:
fooType:
type: string
x-discriminator-value: FooDiscriminator
will lead to:
@JsonSubTypes.Type(value = Foo.class, name = "Foo")
@JsonSubTypes.Type(value = Foo.class, name = "foo")
@JsonSubTypes.Type(value = Foo.class, name = "FooDiscriminator")
tested with 6.2.0
cc @cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @banlevente (2022/02) @Zomzog (2022/09)
I created 2 PRs to resolve this issue - the first one (https://github.com/OpenAPITools/openapi-generator/pull/13802) adds a new configuration option to control the behaviour. This may be preferred as there may be users depending on the multiple schema mapping names. Alternatively, the second one (https://github.com/OpenAPITools/openapi-generator/pull/13815) treats the issue as a bug, and will not add the default mapping name if a custom name or an x-discriminator-value is specified (no additional configuration option). Neither of these PRs prevent a user adding multiple mappings by specifying both a mapping for a discriminator and an x-disciminator-value for the same mapping.
This may be preferred as there may be users depending on the multiple schema mapping names
I think this is the exception to the rule. I believe most people want a one to one mapping, and if the use case arises for multiple, allow people to just specify that, makes the most sense. If I specify a single mapping, why would two generate?
However, I understand that this would be a breaking change for users if they relied on the side effect of producing multiple JSON sub types, but to say it isn't a bug, seems wrong. Further it is evident in the discussion here that in earlier versions it didn't always do this. So it seems like a regression happened somewhere. So with all that said, Im in favor of #13815
With all that said, thank you for the PRs!
Hi, does anybody know how this PR will be merged? I saw it is approved, but the branch not merged yet.
@arandth The advice I've received is that it will likely be included in the 7.0.0 release, scheduled for Q1/Q2 next year.
Oh, that's disappointing that it takes so long to integrate a bug-fix in the tool :-( In the meantime: is there a possibility to use a intermediate built version (e.g. as built from bugfix-branch)?
Thank you for the pull request. I really hope this issue is resolved soon.
Hello, could we reopen this issue? The problem is still there, still getting duplicated JsonSubTypes in 7.0.0 (compared to 5.4.0 for example).
The steps OP provided are still relevant.
update: maybe my issue was something different, however legacyDiscriminatorBehavior removes the duplicate JsonSubTypes
Hello, could we reopen this issue? The problem is still there, still getting duplicated
JsonSubTypesin 7.0.0 (compared to 5.4.0 for example). The steps OP provided are still relevant.update: maybe my issue was something different, however
legacyDiscriminatorBehaviorremoves the duplicate JsonSubTypes
Can confirm, issue had returned and specifying legacyDiscriminatorBehavior: true in the config fixed it again.