openapi-generator [BUG] [JAVA] openapi-generator-maven-plugin does not handle allOf composed of multiple objects

Bug Report Checklist

[x] Have you provided a full/minimal spec to reproduce the issue?
[x] Have you validated the input using an OpenAPI validator (example)?
[x] Have you tested with the latest master to confirm the issue still exists?
[x] Have you searched for related issues/PRs?
[x] What's the actual output vs expected output?
[ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Using allOf composed of multiple objects in a response does not generate a class combining these multiple objects. Instead it uses the first class defined in the allOf section.

openapi-generator version

Version 5.2.0:

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>5.2.0</version>
</plugin>

I have also tested with master (5.2.1-SNAPSHOT), commit fe9636e9.

OpenAPI declaration file content or url

Important part here is the allOf:

openapi: 3.0.0
info:
  title: Test
  version: v1
paths:
  /test:
    get:
      operationId: get
      responses:
        '200':
          description: Get
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/A'
                  - $ref: '#/components/schemas/B'
components:
  schemas:
    A:
      type: object
      properties:
        attA:
          type: string
    B:
      type: object
      properties:
        attB:
          type: integer

Generation Details

generatorName: java
inputSpec: openapi.yaml

Steps to reproduce

 mvn org.openapitools:openapi-generator-maven-plugin:5.2.0:generate \
    -Dopenapi.generator.maven.plugin.inputSpec=openapi.yaml \
    -Dopenapi.generator.maven.plugin.generatorName=java

Shows a warning:

[WARNING] allOf with multiple schemas defined. Using only the first one: A

It generates classes A and B. But when calling get(), the value returned by the call is A:

DefaultApi api = new DefaultApi();
A a = api.get();

I expected instead a composite object with A and B properties (attA and attB), like this (result from https://editor.swagger.io/):

Related issues/PRs

Suggest a fix

Jul 22 '21 09:07 norbjd

any update on this?

Sep 19 '21 10:09 zczhuohuo

The bug is in the code-generator falling back to a raw Object class when both a schema ref and inline is used such as:

...
      responses:
        '200':
          description: Some description
          content:
            application/json:
              schema:
                title: MyCustomClassNameResponse
                allOf:
                  - type: object
                    properties:
                      data:
                        $ref: '#/components/schemas/Dog'
                  - $ref: '#/components/schemas/Pet'
...

If you comment out the first inline object, you end up with just Pet, and if you comment the second reference you end up just with Dog.

As work-around you can edit the spec and introduce your own return type and use a single ref there similar to:

...
      responses:
        '200':
          description: Some description
          content:
            application/json:
              schema:
                  $ref: '#/components/schemas/MyCustomClassNameResponse'
...

Not don't claim you can't edit the spec, simply download it, modify it, check it in your source code and generate from it !!!

Sep 22 '21 01:09 paulbors

@paulbors of course editing the spec is possible (and that's the solution we used now), but this is not very convenient if the openapi evolves : we have to manually change our version to match the new version.

Besides, as you said editing the openapi is just a workaround.

That's why I opened this issue : the fact that the generator does not generate right classes when providing a valid openapi spec (as in my example) is probably a bug and as so probably needs to be fixed.

Sep 22 '21 09:09 norbjd

I was referring to your comments here: https://stackoverflow.com/questions/68773761/openapi-generator-maven-plugin-java-does-not-handle-allof-properly

Right, so we know is not working with:

More than one $ref
A combination of $ref and inline schema

We know it works with:

A single $ref
A full inline schema

So that's the real bug here. Now let's see which one of us (you or me) needs this to work first and puts out a Pull Request to this repo fixing it.

The beauty of open source code... :)

Sep 22 '21 16:09 paulbors

For me a "A single $ref" also doesnt work when using allOf :(

However my case is a bit different:

Customer:
  allOf:
    - $ref: '#/components/schemas/CreateCustomer'
  required:
    - customerId
  properties:
    customerId:
      type: string

I get a java class that only has "customerId" field

Oct 06 '21 21:10 Richardmbs12

Hello everyone,

any progress on this. We have a lot of combined schema and need this functionality. I'm rahter new to OpenAPI, so @paulbors could you please clarify your workaround. I do not get what I have to do. Would appreciate it.

If someone could point me to the specific code where the problem is, I could have a look to fix it.

Nov 15 '21 14:11 maddin79

I guess this is the cause for other issues :

https://github.com/OpenAPITools/openapi-generator/issues/10024
https://github.com/OpenAPITools/openapi-generator/issues/10010
https://github.com/OpenAPITools/openapi-generator/issues/6796

And I have the same issue with html2 generators also...

Nov 17 '21 14:11 nicobo

Also ran into this bug :( In my case i have a spec with ~15k LOC with compositions of cross linked schemas. So editing every allOf to replace it with single inline scheme is not a right way %(

Nov 25 '21 20:11 KSDaemon

I have the same issue also when generating plain models...

Jan 30 '22 18:01 cdprete

In my case, initially I wrote:

  User:
    allOf:
      - $ref: '#/definitions/UserBase'
      - type: "object"
        properties:
          password:
          type: "string"
          format: password

~~Where the correct is:~~ What worked for me is:

  User:
    allOf:
      - $ref: '#/definitions/UserBase'
    type: "object"
    properties:
      password:
        type: "string"
        format: password

After applying the change warning is gone.

I'm using kotlin-spring generator and swagger: "2.0".

Feb 23 '22 13:02 skwasniak

The warning is gone butt still it does not work (using java)

Mar 10 '22 11:03 argenstijn

Can this please be fixed!!

Mar 10 '22 11:03 argenstijn

The warning is gone butt still it does not work (using java)

It works in my case i.e. kotlin and kotlin-spring generators.

$ openapi-generator-cli version
5.4.0

Maybe providing a code snippets would be helpful for fixing it in this case.

Mar 10 '22 14:03 skwasniak

@skwasniak I am not sure if your second option is really correct. On https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/ you can find the following example:

       allOf: # Combines the main `Pet` schema with `Cat`-specific properties 
        - $ref: '#/components/schemas/Pet'
        - type: object
          # all other properties specific to a `Cat`
          properties:
            hunts:
              type: boolean
            age:
              type: integer

What am I getting wrong here?

Mar 22 '22 13:03 koalo

@koalo I'm not saying this is accordingly to open api spec, I'm just stating a workaround that works for kotlin and kotlin-spring generators. But you have the point, my wording "Where the correct is:" is misleading.

Anyhow it is a bug that needs attention, as probably it is widely used feature.

P.S. My API spec is swagger: "2.0".

Mar 22 '22 17:03 skwasniak

Upgrading from swagger v2 to swagger v3 we hit exactly this issue when generating java code.

In swagger v2 codegen, allOf types would nicely be composed.

In swagger v3 only the first type in the allOf would become part of the model...

As the OpenAPITool community seems more active I now upgraded to OpenAPITools codegen.

Although it still logs a nonsense warning about multiple types in allOf (please merge https://github.com/OpenAPITools/openapi-generator/pull/7446 or other PR removing this warning in the correct way!):

[main] WARN o.o.codegen.DefaultCodegen - allOf with multiple schemas defined. Using only the first one: XYZ [main] WARN o.o.codegen.DefaultCodegen - More than one inline schema specified in allOf:. Only the first one is recognized. All others are ignored.

as a matter of fact the generator 5.4.0 does correctly generate the complete composed java model!

Mar 31 '22 21:03 consultantleon

Using 5.4.0 with Java and agree with @consultantleon. The generated model is composed correctly from all schemas defined under the allOf, but this warning message is clearly wrong (allOf is supposed to be used with multiple schemas).

Apr 04 '22 09:04 nikosmoum

I've upgraded to 3.0.3 API version with a help of the generator (openapi-generator-cli generate -i <input_file> -g openapi-yaml) and the result is the following:

    User:
      allOf:
        - $ref: '#/components/schemas/UserBase'
      properties:
        password:
          type: string
          format: password

Generation of kotlin works correctly. openapi-generator-cli version is 5.4.0.

Apr 08 '22 07:04 skwasniak

Also in case of <generatorName>spring</generatorName> there is the same warning and only the first ref is used in the generation of the model. Tested with plugin version 5.4.0 and 6.0.0-beta

Apr 08 '22 14:04 fastluca

@consultantleon @nikosmoum @skwasniak I am not sure how you got a complete composite object. I've tried with the example in my first post, using the latest versions at the time of the plugin (5.4.0 and 6.0.0-beta) and the latest supported openapi spec (3.0.3), and I still got the same result. Maybe you have a different case than the example in my first post.

In my case, the Java DefaultApi class generated looks like this:

public class DefaultApi {
    // ...

    public A get() throws ApiException {
        ApiResponse<A> localVarResp = getWithHttpInfo();
        return localVarResp.getData();
    }

    // ...
}

The get() method does not return a composite object of A and B, but just A.

Also, I've tried with Kotlin:

 mvn org.openapitools:openapi-generator-maven-plugin:5.4.0:generate \
    -Dopenapi.generator.maven.plugin.inputSpec=openapi.yaml \
    -Dopenapi.generator.maven.plugin.generatorName=kotlin

And got the same result (the method get() only return A:

class DefaultApi(basePath: kotlin.String = defaultBasePath) : ApiClient(basePath) {
    // ...

    fun get() : A {
        val localVarResponse = getWithHttpInfo()

        return when (localVarResponse.responseType) {
            // ...
        }
    }

    // ...
}

As @fastluca and others said, the bug is still present.

By the way, these 3 OpenAPI specs parts (replace in my initial openapi.yaml):

schema:
  allOf:
    - $ref: '#/components/schemas/A'
  properties:
    b:
      type: integer

and:

schema:
  allOf:
    - $ref: '#/components/schemas/A'
    - type: object
      properties:
        b:
          type: integer

and:

schema:
  allOf:
    - $ref: '#/components/schemas/A'
  type: "object"
  properties:
    b:
      type: integer

give exactly the same result in Java and Kotlin (get() method always returns A, and the b field does not appear anywhere).

Apr 09 '22 13:04 norbjd

What I can observe with id("org.openapi.generator") version "6.0.1", is that if you define a schema

components:
  schemas:
    CustomQuery:
      allOf:
      - type: object
        required:
        - container
        properties:
          container:
            type: string
            default: '*'
      - $ref: '#/components/schemas/CommonQuery'

Then it will generate two classes, one CustomQuery which has all the fields from the CommonQuery and the locally defined ones, and CustomQueryAllOf which only has the container field.

The same happens if you use allOf directly for a query parameter with will generate a class, like GetMyQueryParameter, and GetMyQueryParameterAllOf, where the first one is correct and the latter one only has the one field. You get the allOf with multiple schemas defined. Using only the first one: ... warning for both.

However, the *AllOf classes were actually unused in the code, but they are wrongly imported instead of the correct type without the AllOf ending, leading to compile errors.

Update: explicitly setting x-all-of-name: CustomQuery seems to fix import the problem.