Interceptor for non blocking operations

[ichrist-gr]

Hello,

i'm using resteasy-reactive and i want to implement an interceptor to check the health status of another rest endpoint.
So, when calling a reactive rest endpoint the method signature will be Uni<?>. The problem is that the method signature of my Interceptor must return Object. Do we have any suggestions on how to implement this via interceptor?

[manofthepeace]

Should not be a problem; you do the following;

    @AroundInvoke
    Object uniInceptor(InvocationContext context) {
        Object ret = null;
        try {
            ret = context.proceed();
            if (ret instanceof Uni) {
                return ((Uni<?>) ret).onFailure().....//do anything here
            }
        } catch (Exception e) {
            log.error("Uni interceptor failed", e);
        }
        return ret;
    }

[ichrist-gr]

If i make an http call that returns a uni, then my uniInterceptor method will return also a Uni<?>.
Could you elaborate more on this?

Thank you

[manofthepeace]

Yes this is exact, context.proceed() will call your http method, so ret will be a Uni<?>. Then you can add basically what you want on that Uni, before you actually return it. So once the Uni will get subscribed to, the "extras" you added to it via the interceptor will also be executed.

[tinyzero4]

What about the case when interceptor itself requests for another resource(reactive way) to check its value and based on the result whether proceed. Also it would be great to have a support for kotlin coroutines

[error]: Build step io.quarkus.arc.deployment.ArcProcessor#registerBeans threw an exception: java.lang.IllegalStateException: An interceptor method must accept exactly one parameter of type javax.interceptor.InvocationContext: java.lang.Object invoke(javax.interceptor.InvocationContext, kotlin.coroutines.Continuation<java.lang.Object>) declared on

[manofthepeace]

@breedish sorry I did miss that message, but was reminded in another discussion. I think using an interceptor for that purpose is not really the best way since you lose type safety as the interceptor must return Object, and maintenance might be much harder. I would suggest using a sort of service class that contains the business logic you need, and others can go through the service and not the restClient api itself. But if you really want to use an interceptor I created a sample app that demonstrate how it could work here; https://github.com/manofthepeace/quarkus-reactive-interceptor

run the app via mvn quarkus:dev in another shell run the following multiple times curl -XGET http://localhost:8080/go

The app will run a "prereq" and if its true will continue with the hello call, and if not will return null. You will see all that logged in the quarkus app console something like this;

2023-07-11 21:28:41,691 INFO  [io.quarkus] (Quarkus Main Thread) reactive-interceptor 1.0.0-SNAPSHOT on JVM (powered by Quarkus 3.2.0.Final) started in 2.234s. Listening on: http://localhost:8080
2023-07-11 21:28:41,694 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2023-07-11 21:28:41,695 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, rest-client-reactive, rest-client-reactive-jackson, resteasy-reactive, resteasy-reactive-jackson, scheduler, smallrye-context-propagation, vertx]
2023-07-11 21:28:46,594 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling prereq, true
2023-07-11 21:28:46,610 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling hello
2023-07-11 21:28:55,512 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling prereq, false
2023-07-11 21:29:01,107 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling prereq, false
2023-07-11 21:29:01,987 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling prereq, true
2023-07-11 21:29:01,990 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling hello
2023-07-11 21:29:02,512 INFO  [org.acm.GreetingResource] (vert.x-eventloop-thread-1) Calling prereq, false