Problem with openApi generation with Java record having attributes starting with "set"

[TheKobe23]

Hi,
Having a record containing several attributes, among other things attributes starting with "set" (e.g. "setting, "setup", ...), these attributes will not be generated correctly in the openapi.json. The project is a Quarkus project.

Example for "setting":

1. Using only @Schema annotation (@Schema Setting setting) leads to a "duplicated" generation in the openapi.json: One time with property name "setting" and additionally one time with name "ting".
2. Using @Schema annotation with a description (@Schema(description = "setting description") Setting setting) leads also to a "duplicated" generation of this property. Both ("setting" and "ting") having now a description in the JSON file
3. Adding additionally "name" to the @Schema (@Schema(name = "setting", description = "setting description") Setting setting) leads to the problem, that only the reference ($ref) will be generated in the opanapi.json, without any other properties like description or type. But with this "name" property, only one entry will be generated: "setting".
4. Same behaviour like point 3, if no @Schema annotation is used... (Setting setting)

I tried also to use an implementation of OASFilter, but I got no improvements...

The configuration of smallrye seems also fine, I guess:

smallrye-openapi:
  info-version: 1.3
  info-title: Some title
  info-description: "Some description"
  servers: []
  store-schema-directory: api-doc/generated/

Do you have an idea, what I could do here to generate a correct openapi spec for attributes beginning with "set" and containing descriptions, types and so on without a duplicated entry were the prefix "set" is cut?

Goal:

"setting" : {
   "description" : "setting description",
   "type" : "object",
   "allOf" : [ {
      "$ref" : "#/components/schemas/Setting"
   } ]
}

[MikeEdgar]

@TheKobe23 is sounds like a bug. Can you post a sample affected class? I will research later today.

[MikeEdgar]

@TheKobe23 there was an issue similar to this that should be fixed in recent versions. Can you reply back with the version output from the Maven dependency plugin?

mvn dependency:list -DincludeArtifactIds=smallrye-open-api-core

[TheKobe23]

Here the output:

[MikeEdgar]

It was fixed in 3.8.0. Please update your dependency to 3.8.0 or later and check it.

[TheKobe23]

I made a test with 3.10.0... and yeah, it seems to work now. Great!

[codespearhead]

@TheKobe23 Can you mark this discussion as answered?