-
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
@Blocking Annotation on "entrypoint" in subclass not detected #38275
Comments
Mind attaching a small sample that behaves the way you describe? Thanks |
Thanks. As far as I remember, JAX-RS annotation do not "stack" like that, maybe @FroMage remembers more? |
I don't think they do, indeed. OTOH, this is not a JAX-RS annotation, and we could make it do whatever we want. But, it's a slippery slope, because it makes sense that all annotations are in the same place to me, or at least that they all have a well-defined composition rule. I do not know how interceptor annotations really compose, though. It's possible that if this were an interceptor annotation it would work, because the bean annotation is on the class and not the interface. So there's certainly precedent, and this feels like a grey area. |
Very much so |
We are encountering the exact same issue in our project. The provided minimal example mirrors our use case, and we are experiencing validation failures with the @Blocking annotation in abstract entrypoint methods when using JAX-RS stubs generated from OpenAPI definitions. I agree that from a design standpoint it might make sense to place the annotations all in the same place but as the interface is generated from an openapi.yaml this is not easy to do without adding custom definitions to the openapi.yaml to generate the @Blocking annotation there. |
I just found this older issue #15940 that had a fix in 2021 so this might be a regression. |
I am also faced this issue with using of @Blocking |
Yes please |
@geoand i've found the case due testing my reproducer 🗡️ if interface declared with @path - ok, as below:
but if you omit @path, then you get non-desired behavior (but honestly i m not sure if that's bug, because it not seems ok to me, if you need to dig into interface to see if it has at least one method with resteasy annotation instead just see at it own root):
Link to REPRODUCER IS HERE: https://github.com/lasteris/quarkus-reproducer-38275 |
Thanks |
Allow the of @Blocking on @ClientExceptionMapper
Relates to: quarkusio#38275 (comment) (cherry picked from commit 9b72af5)
Relates to: quarkusio#38275 (comment) (cherry picked from commit 9b72af5)
Describe the bug
When using the
@Blocking
Annotation in a subclass to define an entrypoint, such as a JAX-RS endpoint that is abstract in the parent class, the validation of the execution model, as introduced in #36327, encounters failures.This is primarily a issue when using jax-rs stubs e.g. when generating from OpenAPI definitions.
Expected behavior
In cases where the entrypoint method is abstract, the implementation in the subclass should be considered for the validation.
Actual behavior
Validation fails with the following errors:
How to Reproduce?
Minimal example:
Output of
uname -a
orver
Darwin NBDVBXXX.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64
Output of
java -version
openjdk version "17.0.6" 2023-01-17 OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10) OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode)
Quarkus version or git rev
3.6.4
Build tool (ie. output of
mvnw --version
orgradlew --version
)Maven home: /Users/XXX/.m2/wrapper/dists/apache-maven-3.8.8-bin/67c30f74/apache-maven-3.8.8 Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: /Users/XXX/.asdf/installs/java/temurin-17.0.6+10 Default locale: en_CH, platform encoding: UTF-8 OS name: "mac os x", version: "14.2.1", arch: "aarch64", family: "mac"
Additional information
No response
The text was updated successfully, but these errors were encountered: