No Panache session in REST endpoints defined by an interface

[danielbobbert]

Describe the bug

When a REST resource is implemented as a CDI bean (without any Jax-RS annotations) that implements an interface (which carries the REST annotations), then invoking a method on this services fails because of a missing Panache session. Error message:

- no reactive session was found in the context and the context was not marked to open a new session lazily
- you might need to annotate the business method with @WithSession
at io.quarkus.hibernate.reactive.panache.common.runtime.SessionOperations.getSession(SessionOperations.java:163)

Expected behavior

The REST services should be executed with an active Panache session, just as if the REST annotations were present on the resource implementation itself.
This used to work in Quarkus 2 without problem.

Actual behavior

If the resource implementation has REST annotations itself, the execution works correctly. If the REST annotations are provided by an interface, invocation fails.

How to Reproduce?

See attached sample project and execute the tests. It contains two resources:

• one with REST annotations on the resource itself
• one which implements an interface that provides the REST annotations

The first resource works as expected, the second resource fails.

Output of uname -a or ver

Darwin dbb-m1.local 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_ARM64_T6000 arm64

Output of java -version

17

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.4.1

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

mvn 3.9.4

Additional information

reactive-session-bug.zip

[quarkus-bot]

/cc @FroMage (panache), @gastaldi (m1), @loicmathieu (panache)

[danielbobbert]

I double checked with Quarkus 3.3, 3.2 and 3.0.4, and they all exhibit the same problem. So it seems to have been introduced with the switch to Quarkus 3.

[gsmet]

@DavideD @mkouba wondering if it could be either related to Hibernate Reactive changes or to CDI changes?

[mkouba]

@DavideD @mkouba wondering if it could be either related to Hibernate Reactive changes or to CDI changes?

Yes, this is definitely a consequence of HR Panache refactoring introduced in quarkus 3.0. We do not open the reactive session automatically when the resource annotations are declared on an interface. The details are explained in the migration guide.

@danielbobbert you can just annotate the resource methods/class with @WithSession or @WithTransaction.

[danielbobbert]

Yes, that's what I am doing right now and it's certainly not a big deal. I still find it kind of inconsistent that you are automatically opening a session when the jax-rs annotations are on the bean itself, but you don't if the annotations are on the interface. From my understanding, there is no semantic difference between the two, and they should behave the same way.

[mkouba]

From my understanding, there is no semantic difference between the two, and they should behave the same way.

Yes, that's my understanding too. However, we only cover the basic use cases. Also keep in mind that @WithSession and @WithTransaction are CDI interceptor bindings and cannot be used on interfaces (CDI inheritance rules are different compared to JAX-RS).

[danielbobbert]

Yes, definitely. And since session management is certainly an implementation-detail I would put those annotations on the service (impl) anyways and not on the interface.
But the question whether you automatically open a session, is a JAX-RS question and not a CDI question, right?! Obviously, putting JAX-RS annotation on the interface (instead of the bean itself) doesn't make a difference in terms of JAX-RS. It's automatically recognized as an endpoint with routing, serialization, exception mapping, etc. all in place.
And your docs state: "In some cases, the session is opened automatically on demand. For example, if a Panache entity method is invoked in a JAX-RS resource method".
There's no addition "but only, if you happen to put your JAX-RS annotations in the right place". How do you actually check whether "a Panache entity method is invoked in a JAX-RS resource method"? Is this explicitly checking for some annotations (then it should be easy to collect those annotations from interfaces as well)? Or is there some other subtle difference at runtime, depending on how the JAX-RS resource is defined?
Anyways: as we already agreed, it's easy to fix (by putting @WithSession on the bean), it's just a bit counter-intuitive that it behaves differently. So feel free to fix it, or just close the issue.

[FroMage]

How hard would it be to support this, @mkouba ?

[mkouba]

How do you actually check whether "a Panache entity method is invoked in a JAX-RS resource method"? Is this explicitly checking for some annotations (then it should be easy to collect those annotations from interfaces as well)? Or is there some other subtle difference at runtime, depending on how the JAX-RS resource is defined?

@danielbobbert We add @WithSessionOnDemand to a method that

• is not static,
• is not synthetic,
• returns Uni,
• is declared in a class that uses a panache entity/repository,
• is annotated with an HTTP method designator (@GET, @POST, @PUT, @DELETE ,@PATCH ,@HEAD or @OPTIONS),
• and is not annotated with @ReactiveTransactional, @WithSession, @WithSessionOnDemand, or @WithTransaction.

https://github.com/quarkusio/quarkus/blob/main/extensions/panache/hibernate-reactive-panache-common/deployment/src/main/java/io/quarkus/hibernate/reactive/panache/common/deployment/PanacheJpaCommonResourceProcessor.java#L104-L182

How hard would it be to support this, @mkouba ?

@FroMage I'm not sure. In theory, we could modify the logic and instead of transforming method annotations we could transform annotations of a resource class. In any case, we would also need to scan the class hierarchy for interfaces with JAX-RS annotations...

[danielbobbert]

Am I correct that your code currently only catches "direct" usage of Panache? If the JAX-RS resource uses an injected service bean, which in turn uses an injected Panache repository (but is not a Panache repository itself), then this case would not be detected by the current code either, right?!

[mkouba]

Am I correct that your code currently only catches "direct" usage of Panache? If the JAX-RS resource uses an injected service bean, which in turn uses an injected Panache repository (but is not a Panache repository itself), then this case would not be detected by the current code either, right?!

Yes, that would be a non-trivial task to analyse all the injected services or detect any indirect usage of panache.

And it was not a goal to cover these scenarios.

[FroMage]

In any case, we would also need to scan the class hierarchy for interfaces with JAX-RS annotations.

Not just scan, also find out what method we're overriding, which includes resolving type parameters and all…

Perhaps the easiest is to add this message to the exception:

- This automatically works from JAX-RS annotated methods (not via an interface)

So at least, we make it clear where it works and not?

[mkouba]

In any case, we would also need to scan the class hierarchy for interfaces with JAX-RS annotations.

Not just scan, also find out what method we're overriding, which includes resolving type parameters and all…

Well, I was thinking that we could add @WithSessionOnDemand to the class, not specific methods, i.e. if a class implements a JAX-RS resource then just annotate the class with @WithSessionOnDemand and all methods returning Uni would have a session opened automatically.

The downside of this approach is that if a method is annotated e.g. with @WithSession then we would intercept the method twice which is suboptimal.

Perhaps the easiest is to add this message to the exception:

Yes, that makes sense. I'll send a PR.