OpenAPI: auto-add-tags feature uses superclass/interface name, rather than actual class name

[j-be]

Describe the bug

Consider the following:

@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public interface AbstractReadOnlyResource<T> {
    @GET
    @Path("/{id}")
    T getById(@PathParam("id") long id);
}

and

@Path("/address")
public class AddressResource implements AbstractReadOnlyResource<Address> {
    @Override
    public Address getById(long id) {
        // Removed for brevity
    }
}

Expected behavior

The get operation of the /address/{id} path is tagged with Address Resource.

Actual behavior

The resource is tagged with Abstract Read Only Resource.

OpenAPI JSON contains

"paths" : {
  "/address/{id}" : {
    "get" : {
      "tags" : [ "Abstract Read Only Resource" ],
      "parameters" : [ {
        "name" : "id",
        "in" : "path",
        "required" : true,
        "schema" : {
          "format" : "int64",
          "type" : "integer"
        }
      } ],
    }
  }
}

Swagger UI shows:

How to Reproduce?

Will add a link to a GitHub repo shortly.

EDIT: A small reproducer project can be found here.

Output of uname -a or ver

Linux jbe-desktop 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "11.0.11" 2021-04-20

GraalVM version (if different from Java)

none

Quarkus version or git rev

2.4.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)

Additional information

No response

[quarkus-bot]

/cc @EricWittmann, @MikeEdgar, @phillip-kruger

[phillip-kruger]

As a workaround you can add the @Tag annotation

[j-be]

@phillip-kruger @geoand Cannot confirm, issue persists in 2.5.1.Final, even though differently now. Seems I can't reopen the issue, though.

If I have 2 resources inheriting, both carry the same tag (not sure how it determines which tag to use).

Consider the following:

@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public interface AbstractReadOnlyResource<T> {
    @GET
    @Path("/{id}")
    T getById(@PathParam("id") long id);
}

and

@Path("/address")
public class AddressResource implements AbstractReadOnlyResource<Address> {
    @Override
    public Address getById(long id) {
        // Removed for brevity
    }
}

and

@Path("/person")
public class PersonResource implements AbstractReadOnlyResource<Person> {
    @Override
    public String getById(long id) {
        // Removed for brevity
    }
}

Expected behavior

• The get operation of the /address/{id} path is tagged with Address Resource.
• The get operation of the /person/{id} path is tagged with Person Resource.

Actual behavior

Both resources carry the same tag, but it seems to be random which one of the two.

I updated my reproducer here.

EDIT: Fix examples above and typos.

[phillip-kruger]

thanks ! I'll have a look a.s.a.p

[phillip-kruger]

This is fixed in SmallRye, and will be fixed in Quarkus as soon as we update the version after release. This should be later this week

[j-be]

@phillip-kruger that is excellent news! thank you very much, looking forward to the release 😄

[j-be]

@phillip-kruger Quarkus 2.6.2.Final was a further improvement, but still not quite there. If there is an abstract class between interface and implementation it still doesn't work correctly.

Consider:

public abstract class AbstractRestResourceImpl implements AbstractReadOnlyResource<String>{
    abstract protected String getPrefix();

    @Override
    public String getById(long id) {
        return getPrefix() + " " + id;
    }
}

and

@Path("/address")
public class AddressResource extends AbstractRestResourceImpl {
    @Override
    protected String getPrefix() {
        return "Disney Land, Gate";
    }
}

Rest as before.

This results in

paths:
  /address/{id}:
    get:
      parameters:
      - name: id
        in: path
        required: true
        schema:
          format: int64
          type: integer
      responses:
        "200":
          description: OK
          content:
            text/plain:
              schema:
                type: object

i.e., no tags.

I updated https://github.com/j-be/quarkus-21173 to reflect the issue.

[MikeEdgar]

@phillip-kruger feel free to assign this to me. I think it's actually fixed by #27206 and the test needs to be modified.

[phillip-kruger]

Thanks @MikeEdgar !