Openapi-generator: [BUG] [JAVA] Java generation of 'extra' class with allOf

[renskesterrenburg]

Description

I am using the pet store example to create java classes with inheritance. In the newest release (4.0.1) I found a bug. When I generate code with the OpenApi declaration file it generates an extra class.

The class 'CatAllOf' I did not expect. It looks the same as 'Cat' except that it does not extends Pet.

OpenAPI declaration file:

openapi: 3.0.1
info:
  title: Article Event
  description: 'Article Event schema'
  version: 1.0.0
paths:
  /:
    get:
      responses:
        200:
          description: OK
          content: {}
components:
  schemas:
    TextChunk:
      type: object
      discriminator:
        propertyName: textChunkType
      properties:
        parent:
          type: string
    Dog:
      allOf: 
      - $ref: '#/components/schemas/TextChunk'
      - type: object
    Cat:
      allOf:
      - $ref: '#/components/schemas/TextChunk'
      - type: object
        properties:
          bark:
            type: string

openapi-generator version
I used the gradle plugin with version 4.0.1.

older version
I tested the same thing in the version 4.0.0-beta3 and there I did net see the 'extra' class. In other words, I got the expected behavior. It seems the bug was introduced with the latest release.

[msymonov]

And it's not about presence of extra class only. The expected inheritance is missing as well.
It seems to me that the whole 4.x is affected

[gerardbosch]

I'm facing this issue as well. But when I have realized the version 4 of generator working this way I asked myself if this was intended or really a weird bug. Could someone clarify it? I was pretty happy with 3.3.4 so I will go back to it for now. I rely on Java inheritance.
@wing328

[frankyjuang]

Also happen in csharp client and server https://github.com/OpenAPITools/openapi-generator/issues/3338

[wing328]

      - type: object
        properties:
          bark:
            type: string

That's treated as an inline schema (which can be replaced with $ref to avoid the additional model generation).

If users prefer the old way of not generating this inline schema, technically we can add an option to restore the old behaviour.

[valliman]

The proposed solutions would lead to a file being generated for the inline schema again. That sounds a bit counter-intuitive. Why would I want to give the inline schema a dedicated name, if I didn't had the need before?

[valliman]

@wing328 any comment on my post above? Is it possible to add the option to add the old behaviour?

[roxspring]

That's treated as an inline schema (which can be replaced with $ref to avoid the additional model generation).

This seems to miss the point entirely. Spec authors understand that these are inline schemas and are used precisely "to avoid the additional model generation". Replacing with a $ref necessitates the creation of the additional model that spec authors wish to avoid.

If users prefer the old way of not generating this inline schema, technically we can add an option to restore the old behaviour.

It seems clear from the number of bugs raised in this area that many users do "prefer the old way". What I'm really not clear on is:

1. What benefits there are to "the new way" - i.e. whether it's worth keeping both ways as options
2. Where in the codebase I should be looking to patch in order to address the underlying problem

[nexen505]

Still got this problem on 4.2.2.

[ahokkonen]

This is also a behavior for .net generators. Still an issue in 4.3.0

[papegaaij]

Even the examples have this issue. For example, the Java RestEasy example has several files with AllOf, like this one https://github.com/OpenAPITools/openapi-generator/blob/v4.3.0/samples/client/petstore/java/resteasy/src/main/java/org/openapitools/client/model/CatAllOf.java

These files are not used at all by the API. The only reference to this class is an unused import from Cat and the testcase CatAllOfTest. The same is true for the other AllOf classes.

[wing328]

What about using .openapi-generator-ignore (in the output directory) to skip those files from being generated?

[papegaaij]

@wing328 That seems like a strange solution to me. Why would I need to ignore files that shouldn't have been generated in the first place? Also, as I said, the classes are referenced by an unused import from other classes. Deleting the files, breaks the build.

[ahokkonen]

What about using .openapi-generator-ignore (in the output directory) to skip those files from being generated?

Great! Using .openapi-generator-ignore including "*/AllOf.cs" for .net generation solves this.
Yes, this is a workaround, but still valid solution for my needs.

[wing328]

Understood that not all users want these allOf classes. The original PR is try to make the behavior consistent (generating a model for inline schema) but clearly not everyone likes it.

I'll think about this more and see what I can do, probably in the upcoming 5.0.x release in May/Jun in which breaking changes are expected.

[gerardbosch]

Good news to listen about restoring to the original behavior. We rely upon inheritance that the v3.x provided, i.e. class Cat extends Animal (or as per OP example Cat extends TextChunk), which seems missing in v4.x.

[wing328]

We rely upon inheritance that the v3.x provided

That's not going to be restored.

You will need to use discriminator for inheritance: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#models-with-polymorphism-support

[sko-ob]

@wing328 That seems like a strange solution to me. Why would I need to ignore files that shouldn't have been generated in the first place? Also, as I said, the classes are referenced by an unused import from other classes. Deleting the files, breaks the build.

Facing the same issue here, where configuring the generator to ignore these AllOf files causes the classes to not compile due to these AllOf classes being imported (even though they're unused). Using Java here.

[jharmelink]

Can someone explain why these *AllOf.java files are being generated in the first place?

[gerardbosch]

We rely upon inheritance that the v3.x provided

That's not going to be restored.

You will need to use discriminator for inheritance: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#models-with-polymorphism-support

(Sorry for the bit delay...)

Sure @wing328 we use the discriminator to allow inheritance on model classes be generated (at least in the generator v3.x). But the whole point is that the v4.x does not generate the inheritance in the Java classes. So this is the behavior that was broken and that we would like to recover back.

Aside of that, and as others state, the new generated classes *AllOf.java in v4.x seems not useful at all and pollutes the generated artifact.

Is there any news for the v5.x you mentioned regarding the inheritance issue? Thanks!! 🙏 😃

[gerardbosch]

I've just realized that I have been confused on all my previous assertions regarding inheritance. The inheritance is not actually broken and seems never was (I've tried again with several generator versions 4.0, 4.02, 4.0.3, 4.1, 4.3.1) and Java inheritance is still fine. So I apologize if I introduced noise. I think other commenter stated the inheritance was broken as well.

So the actual problem is only about the extra unuseful AllOf generated classes (this ones are the ones that has no inheritance, but for the sake of the issue are the ones we want to remove).

The main point is that this pollutes the generated JAR with unnecessary, unused classes, so breaks the point of a sane API artifact.

I've just tried using the .openapi-generator-ignore file with **/*AllOf.java in output directory, and as others already said, classes are not generated, BUT the unused imports in other classes (say Cat.java) prevents the code to compile.

Maybe I could hack the POM of my generator (here using openapi-generator-maven-plugin) to remove all ^import.*AllOf;$ using sed or something similar but this is not the right way to go. Could work as a patch at most.

[gmcelhoe]

the unused imports in other classes (say Cat.java) prevents the code to compile.

That seems like the most solvable problem -- if the generated file only imported classes it used, then the .openapi-generator-ignore trick would work.

[surmabck]

As a workaround I can suggest adding additionalProperties: true to _child_ schema.
For example, below would not generate additional CatAllOf.java

Cat:
   allOf:
   - $ref: '#/components/schemas/TextChunk'
   - type: object
     additionalProperties: true
     properties:
       bark:
         type: string

That works because composed schema (allOf, oneOf, anyOf) that also defines additionalProperties are considered to be a MapSchema and models are not generated for MapSchemas.
I haven't encountered any problems so far with this solution so far, but I have not tested other generators

[gerlacdt]

Are there any news about this? Is it on the roadmap for the upcoming 5.x release?

[milczarekIT]

When you change from:

Cat:
      allOf:
      - $ref: '#/components/schemas/TextChunk'
      - type: object
        properties:
          bark:
            type: string

To:

Cat:
   type: object
   properties:
      bark:
         type: string   
   allOf:
      - $ref: '#/components/schemas/TextChunk'

So, if additional properties for Cat are added to the root of Cat, then there is no additional class CatAllOf

[skchande]

Very nice Workaround @milczarekIT
I have tested it with openapi-generator version 5.0.0-beta2.

Does anyone know if this behavior is intended? I could not find any documentation for this.

[MattLichter]

@milczarekIT Nice workaround. It allowed me to generate the intended client code without the dummy classes (I'm using csharp-netcore 5.0.0-SNAPSHOT).

Does anyone know if this is still valid OpenAPI syntax though? I haven't found any official examples with this structure.

[thobiaskarlsson]

That is a nice workaround. Sadly for Java the "builder" methods does not work since they return the super type, e.g.

Dog dog = new Dog().bark(true); // Ok since "bark" belongs to Dog

Pet dog = new Dog().bark(true).name("Doggie"); // Returns Pet (since "name" belongs to Pet), should return Dog



md5-fe5d79f72da2036a7b2f9474e885116a



Dog dog = (Dog) new Dog().bark(true).name("Doggie");



md5-a043681440dc45d7d72b5c39ab0245e8



Dog dog = new Dog().bark(true);
dog.name("Doggie"); // <- Pet



md5-a043681440dc45d7d72b5c39ab0245e8



Dog dog = new Dog();
dog.setBark(true);
dog.setName("Doggie");



md5-38916eadfb3b57de8f2418b1a96c3872



@Override
public Dog name(String name) {
  return (Dog) super.name(name);
}

Then this workaround would be very acceptable imo.