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

@Blocking Annotation on "entrypoint" in subclass not detected #38275

Open
raphael-gosteli opened this issue Jan 18, 2024 · 13 comments
Open

@Blocking Annotation on "entrypoint" in subclass not detected #38275

raphael-gosteli opened this issue Jan 18, 2024 · 13 comments
Labels
kind/bug Something isn't working

Comments

@raphael-gosteli
Copy link

raphael-gosteli commented Jan 18, 2024

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:

Wrong usage(s) of @Blocking found:
        - com.example.TestImpl.getDocument(java.util.UUID)
The @Blocking, @NonBlocking and @RunOnVirtualThread annotations may only be used on "entrypoint" methods (methods invoked by various frameworks in Quarkus)
Using the @Blocking, @NonBlocking and @RunOnVirtualThread annotations on methods that can only be invoked by application code is invalid

How to Reproduce?

Minimal example:

public abstract class TestResource {
   @Path("test")
   public abstract Response getDocument(UUID uuid);
}
@ApplicationScoped
public class TestResourceImpl extends TestResource {

    @Override
    @Blocking
    public Response getDocument(UUID uuid) {
        return Response.ok().build();
    }
}

Output of uname -a or ver

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 or gradlew --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

@raphael-gosteli raphael-gosteli added the kind/bug Something isn't working label Jan 18, 2024
@geoand
Copy link
Contributor

geoand commented Jan 18, 2024

Mind attaching a small sample that behaves the way you describe?
It would be helpful in coming up with a fix and adding a proper test for it.

Thanks

@raphael-gosteli
Copy link
Author

@geoand sure, here is a sample using Quarkus 3.6.6

@geoand
Copy link
Contributor

geoand commented Jan 22, 2024

Thanks.

As far as I remember, JAX-RS annotation do not "stack" like that, maybe @FroMage remembers more?

@FroMage
Copy link
Member

FroMage commented Jan 22, 2024

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.

@geoand
Copy link
Contributor

geoand commented Jan 22, 2024

So there's certainly precedent, and this feels like a grey area

Very much so

@mh03r932
Copy link

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.

@mh03r932
Copy link

I just found this older issue #15940 that had a fix in 2021 so this might be a regression.

@lasteris
Copy link
Contributor

lasteris commented May 16, 2024

I am also faced this issue with using of @Blocking
with @ClientExceptionMapper in RestClient. Do i need to create a reproducer ? (Quarkus 3.10.0)

@geoand
Copy link
Contributor

geoand commented May 16, 2024

Yes please

@lasteris
Copy link
Contributor

lasteris commented May 16, 2024

@geoand i've found the case due testing my reproducer 🗡️

if interface declared with @path - ok, as below:

@RegisterRestClient(configKey = "google-client")
@Path("/")
public interface BrokenBlockingApi {
....

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):

@RegisterRestClient(configKey = "google-client")
//@Path("/")
public interface BrokenBlockingApi {

Link to REPRODUCER IS HERE: https://github.com/lasteris/quarkus-reproducer-38275

@geoand
Copy link
Contributor

geoand commented May 16, 2024

Thanks

@geoand
Copy link
Contributor

geoand commented May 20, 2024

@lasteris #40721 fixes your issue

@lasteris
Copy link
Contributor

@lasteris #40721 fixes your issue

Thank you, that was really quick. Cool 💯

geoand added a commit that referenced this issue May 20, 2024
Allow the of @Blocking on @ClientExceptionMapper
gsmet pushed a commit to gsmet/quarkus that referenced this issue May 21, 2024
holly-cummins pushed a commit to holly-cummins/quarkus that referenced this issue Jul 31, 2024
gsmet pushed a commit to gsmet/quarkus that referenced this issue Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants