-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Allow the use of @Blocking on @ClientExceptionMapper #40721
Conversation
geoand
commented
May 20, 2024
- Relates to: @Blocking Annotation on "entrypoint" in subclass not detected #38275 (comment)
I believe none of the other extension handling @Blocking handle this case. @ozangunalp do you know about reactive messaging? |
That's a very good point, however the REST client might be unique in that the various Providers are run on the event loop by default (which was probably a mistake) |
@cescoffier if you ask whether we produce an |
For messaging, we only detect incoming/outgoing annotated methods on beans and not from superclasses. |
Status for workflow
|
@cescoffier is gRPC exception handler is a plain ServerCall.Listener impl, which I guess could work with blocking, if there is a @Blocking before on the method |
Ok, so, messaging and gRPC - only for the concrete method. WS and REST: super-method too. We may need to make this a bit more homogenous (BTW does @Blocking has the inherent meta-annotation?) |
Hm, I'm not quite following. WS Next does not support class-level
Keep in mind that |
Reproducer for this fix: quarkusio/quarkus#40721
Reproducer for this fix: quarkusio/quarkus#40721
Reproducer for this fix: quarkusio/quarkus#40721
Reproducer for this fix: quarkusio/quarkus#40721 (cherry picked from commit a2f4bc1)
Reproducer for this fix: quarkusio/quarkus#40721 (cherry picked from commit a2f4bc1)