@Blocking on resource is ignored if implementing an OpenAPI-generated interface

[famod]

Describe the bug

When generating interfaces from a OpenAPI defintion file via https://github.com/OpenAPITools/openapi-generator, all Jax-RS annotations are added to the interface so you don't have to repeat them in your actual resource that implements the interface.
If you decide that you need @Blocking, you have to put it in the interface to have it recognized.

Expected behavior

Since blocking or not is an implementation detail, I should not be forced to put this in the (generated) resource interface.

Actual behavior

As soon as a resource implements an interface that contains alls the Jax-RS annotations, @Blocking on the actually implemented methods (or the resource class) is ignored.

To Reproduce

quarkusio/quarkus-quickstarts@main...famod:issue-15940

Steps to reproduce the behavior:

1. git clone https://github.com/famod/quarkus-quickstarts.git
2. git switch issue-15940
3. cd getting-started-reactive
4. mvn verify (no error)
5. remove @Blocking from ReactiveGreeting.greeting()
6. mvn verify (error regarding IO thread)

Configuration

quarkus.datasource.db-kind=h2
quarkus.datasource.username=sa
quarkus.datasource.password=sa
quarkus.datasource.jdbc.url=jdbc:h2:mem:test_quarkus;DB_CLOSE_DELAY=-1

Environment (please complete the following information):

Output of uname -a or ver

Linux XXX 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.24.0, JRE 11 Linux amd64-64-Bit Compressed References 20210120_910 (JIT enabled, AOT enabled)
OpenJ9   - 345e1b09e
OMR      - 741e94ea8
JCL      - 0a86953833 based on jdk-11.0.10+9)

(also happens with HotSpot)

GraalVM version (if different from Java)

Quarkus version or git rev

1.12.2

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

Apache Maven 3.6.3

Additional context

[quarkus-bot]

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

[famod]

I think this is more something for you @cescoffier or @geoand or @FroMage.

[geoand]

We could certainly also consult the implementation class (it makes perfect sense to do so), however this seems to be a general issue - we only seem to consult the annotation from the interface.

@FroMage do you remember if the spec mentions something specific about annotations on the interface vs the impl class?

[FroMage]

https://quarkus.io/specs/jaxrs/2.1/index.html#annotationinheritance says:

If a subclass or implementation method has any JAX-RS annotations then all of the annotations on the superclass or interface method are ignored.

So we should look at whatever source has any JAX-RS annotation. Also note that superclass is favoured over superinterfaces.

[geoand]

Very interesting, thanks!

[famod]

So we should look at whatever source has any JAX-RS annotation

Which wouldn't solve my problem, would it?

I do understand the spec part, but io.smallrye.common.annotation.Blocking isn't really a JAX-RS annotation, IMO.

[geoand]

It isn't true, but I am not entirely convinced we should differentiate the standard behavior here.

[famod]

Right now, this issue is not a big deal for my current project. We just add it to a mustache template we have to override anyway and everything is blocking (which suites our current needs).

But as soon as we want to have certain calls non-blocking, things will become verbose:
We would either need to introduce a vendor extension to control when to generate @Blocking, which pollutes the OpenAPI file with internals.
Or we would need to use that Infrastructure-something class (don't have the code in front of me right now) to make all respective Mutiny calls blocking, one by one.

[geoand]

I see your point. I'll think about it a bit more

…

On Wed, Mar 24, 2021, 00:19 Falko Modler ***@***.***> wrote: Right now, this issue is not a big deal for my current project. We just add it to a mustache template we have to override anyway and everything is blocking (which suites our current needs). But as soon as we want to have certain calls non-blocking, things will be come verbose: We would either need to introduce a vendor extension to control when to generate @Blocking, which pollutes the OpenAPI file with internals. Or we would need to use that Infrastructure-something class (don't have the code in front of me right now) to make all respective Mutiny calls blocking. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15940 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBMDP7UJTFGBTRF3K6RMWTTFEHWTANCNFSM4ZUCDGBQ> .

[geoand]

#15987 should take care of it

[famod]

@geoand Thanks a lot for this rapid turnaround!

[geoand]

YW!