Why are some enums shown with with every value twice?

[cristalp]

I have an enum which looks like this:

public enum RegisterHistoryEnvironment {

  XML,

  DATABASE;
}

This is rendered with every value twice:

In the code, that's how it's defined:

      @Parameter(required = false, description = "...")
      @QueryParam("environment") @DefaultValue("DATABASE") final RegisterHistoryEnvironment environment

And this is how it's generated:

         {
          "name" : "environment",
          "in" : "query",
          "required" : false,
          "schema" : {
            "allOf" : [ {
              "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
            }, {
              "default" : "DATABASE"
            } ]
          }

With our old toolchain it was generated like this:

        {
          "name" : "environment",
          "in" : "query",
          "schema" : {
            "type" : "string",
            "enum" : [ "XML", "DATABASE" ],
            "default" : "XML"
          }
        }

And that showed the correct drop-down values in SwaggerUI.

If I omit the default value, it's generated in a different way and then shows the correct drop-down values in SwaggerUI:

        {
          "name" : "environment",
          "in" : "query",
          "required" : false,
          "schema" : {
            "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
          }
        }

Am I doing something wrong or is SmallRye generated something it shouldn't?

[MikeEdgar]

How does RegisterHistoryEnvironment appear under components/schemas ?

[cristalp]

It's generated like this:

      "RegisterHistoryEnvironment" : {
        "enum" : [ "XML", "DATABASE" ],
        "type" : "string"
      }

But perhaps I was misleaded. In fact, the class in question is abstract and resides in a dependency which is required when the actual REST endpoints are used in another Maven project. So, project A contains the abstract REST endpoint, and project B uses project B by extending the abstract class. And it's in project B that the openapi.json is generated.

To make things easier to test, I generated openapi.jsondirectly in project A, but apparently the results are different.

So, in fact it looks like this in project B:

        {
          "name" : "environment",
          "in" : "query",
          "required" : false,
          "schema" : {
            "allOf" : [ {
              "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
            }, {
              "default" : "DATABASE"
            }, {
              "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
            }, {
              "default" : "DATABASE"
            } ]
          }
        }


      "RegisterHistoryEnvironment" : {
        "enum" : [ "XML", "DATABASE" ],
        "type" : "string"
      }

[MikeEdgar]

Yuck, that's not good... this is how your endpoint is defined? Can you show the full method signature with annotations too?

@Parameter(required = false, description = "...")
@QueryParam("environment") @DefaultValue("DATABASE") final RegisterHistoryEnvironment environment

[cristalp]

Ok, I created a simple example in project A:

  @GET
  @Path("/foo")
  @Produces({ MediaType.APPLICATION_JSON })
  @Operation(summary = "...")
  public Response foo(
      @Parameter(required = false)
      @QueryParam("environment") @DefaultValue("DATABASE") final RegisterHistoryEnvironment environment) {
    return Response.ok().build();
  }

This results in the following in opernapi.json in project B:

    "/api/foo" : {
      "get" : {
        "summary" : "...",
        "parameters" : [ {
          "name" : "environment",
          "in" : "query",
          "required" : false,
          "schema" : {
            "allOf" : [ {
              "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
            }, {
              "default" : "DATABASE"
            }, {
              "$ref" : "#/components/schemas/RegisterHistoryEnvironment"
            }, {
              "default" : "DATABASE"
            } ]
          }
        } ],
        "responses" : {
          "200" : {
            "description" : "OK"
          }
        }
      }
    }

By the way, I'll be away on holidays for the next two weeks, so please be patient with answers after today :-)

[cristalp]

@MikeEdgar Back from holidays :-) Any news on this question?

[MikeEdgar]

This is still on my radar. I need to get release 4.0 done then plan to come back and get some bug fixes/minor enhancements done in the next few weeks.

[cristalp]

Ok, great! So will this be part of release 4.0 or part of release 3.x.x?

[MikeEdgar]

4.0.x for sure. If it's not too complicated to backport to 3.1.x then it can be queued up for a bug fix there as well.

[cristalp]

Thanks a lot!

[cristalp]

I just tested it with 4.0.0, works great!

[MikeEdgar]

I don't know that it was fixed on purpose or just as a result of the other changes for 4.0 🤣

[cristalp]

Collateral bugfixing :-))