quarkus
quarkus copied to clipboard
Can't use GlobalInterceptor gRPC annotation with interceptor produced by a method
Describe the bug
I have a server interceptor produced by a method:
@Produces
public ServerInterceptor serverInterceptor() {
return new LoggingServerInterceptor();
}
I want to make it global by putting io.quarkus.grpc.GlobalInterceptor annotation.
I can't put this annotation on the producer method, because the annotation has @Target({ FIELD, PARAMETER, TYPE })
(not applicable to methods).
And I can't put this annotation on LoggingServerInterceptor class, because the class does not have any CDI bean annotations on it. Quarkus complains:
2021-11-11 04:23:49,640 ERROR [io.qua.grp.run.GrpcServerRecorder] (main) Unable to start the gRPC server: java.lang.IllegalArgumentException: Server interceptor class class com.azul.cc.infrastructure.grpc.LoggingServerInterceptor is not a CDI bean. Only CDI beans can be used as gRPC server interceptors. Add one of the scope-defining annotations (@Singleton, @ApplicationScoped, @RequestScoped) on the interceptor class.
Expected behavior
The GlobalInterceptor annotation should support this case as well.
Actual behavior
No response
How to Reproduce?
No response
Output of uname -a
or ver
No response
Output of java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.4.1.Final
Build tool (ie. output of mvnw --version
or gradlew --version
)
No response
Additional information
No response
/cc @cescoffier, @michalszynkiewicz
@vladykin Thank you for your report!
A workaround, if you cannot add a scope-defining annotation on the interceptor class, would be to subclass it and add the annotations on the subclass:
@ApplicationScoped
@GlobalInterceptor
public class MyLoggingServerInterceptor extends LoggingServerInterceptor {
}
I took a deeper look into it and it's not trivial to implement. Moreover, I believe the workaround above should let users handle all their use cases. Please let me know if it doesn't work for you.
Thank you, I can use the suggested workaround or put the CDI annotation directly on the LoggingServerInterceptor. My personal preference is to use producer methods for constructing and configuring beans, but if that's not possible in this case, I can live with that.
I understand it's more convenient in some cases, I'm not closing this issue. What I wanted to say is that, having a work around, and being non-trivial, I don't consider this a high priority feature request.
I stumbled on this issue and I was wondering, would it be possible to use the Produces
annotation at least for service scoped interceptors? It would be nice to reuse existing interceptors without wrapping them in new classes.