Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quarkus-smallrye-openapi doesn't take in account ServerExceptionMapper annotations #31828

Closed
SMakhrov opened this issue Mar 13, 2023 · 5 comments
Labels

Comments

@SMakhrov
Copy link

Describe the bug

I've added swagger ui according this doc https://quarkus.io/guides/openapi-swaggerui
Also I have mapped exception annotated by @ServerExceptionMapper

public class ExceptionMappers {

    @ServerExceptionMapper
    public Uni<Response> mapException(MyCustomException e) {
        return Uni.createFrom().item(() -> Response.status(Response.Status.CONFLICT)
                .entity(Map.of("message", "my message"))
                .build());
    }
}

Is there any way to make swagger take in account response codes from ExceptionMappers?

Expected behavior

Generated UI I take in account error responses which are generated by mappers annotated by @ServerExceptionMapper

Actual behavior

Generated UI I does't see error responses which are generated by mappers annotated by @ServerExceptionMapper

How to Reproduce?

Just create class as in but description and add swagger ui according to https://quarkus.io/guides/openapi-swaggerui

Output of uname -a or ver

Darwin mypc 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:35:58 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T6000 arm64

Output of java -version

11.0.11 (x86_64) "AdoptOpenJDK"

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.4.Final

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

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/smakhrov/.m2/wrapper/dists/apache-maven-3.8.6-bin/67568434/apache-maven-3.8.6
Java version: 17.0.4, vendor: GraalVM Community, runtime: /Library/Java/JavaVirtualMachines/graalvm-ce-java17-22.2.0/Contents/Home
Default locale: en_DE, platform encoding: US-ASCII
OS name: "mac os x", version: "12.3", arch: "aarch64", family: "mac"

Additional information

No response

@SMakhrov SMakhrov added the kind/bug Something isn't working label Mar 13, 2023
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 13, 2023

/cc @EricWittmann (openapi), @Ladicek (smallrye), @MikeEdgar (openapi), @jmartisk (smallrye), @phillip-kruger (openapi,smallrye), @radcortez (smallrye)

@phillip-kruger
Copy link
Member

OpenAPI can not figure out the response code from the annotation, so you will have to add OpenAPI annotations to your method.

Try adding something like this:

@APIResponses({
            @APIResponse(responseCode = "123", description = "Your description"),
            @APIResponse(responseCode = "456", description = "Your description")
    })

@SMakhrov
Copy link
Author

Thank you! It works for me.
@phillip-kruger , sorry, another little question: is it possible to generate yaml file with open-api spec during build of application? According to guide https://quarkus.io/guides/openapi-swaggerui I see that is only possible via endpoint $ curl http://localhost:8080/q/openapi

@phillip-kruger
Copy link
Member

Yes, you can store the schema generated by Quarkus during build by using quarkus.smallrye-openapi.store-schema-directory
(see https://quarkus.io/guides/openapi-swaggerui#quarkus-smallrye-openapi_quarkus.smallrye-openapi.store-schema-directory)

Example: Adding this to your config quarkus.smallrye-openapi.store-schema-directory=target/generated will store the generated json and yaml formats in target/generated.

Note: This exclude anything added during runtime, example custom filters.

@MikeEdgar
Copy link
Contributor

@SMakhrov , @phillip-kruger - is there anything else for this issue or can it be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants