gRPC implementation not registered in multi-module project when implementing generated interface

[kristijan-rusu]

Describe the bug

In a multi-module maven project, if you want to share your .proto files between client / server modules, server implementation does not work if you extend the Quarkus Mutiny generated interface.

Expected behavior

The implementation when extending the generated Quarkus Mutiny interface to be registered as gRPC implementation.

Actual behavior

The implementation when extending the generated Quarkus Mutiny interface is not injected in io.quarkus.grpc.runtime.GrpcContainer, thus not registered as a gRPC implementation. This is because the generated interface does not implement io.grpc.BindableService which is injected in the container class.

How to Reproduce?

Reproducible project:
org.example.zip

Steps to reproduce the behaviour:

1. Invoke mvn install on example-api module.
2. Start client service (client module)
3. Start server service (server module)
4. Invoke HTTP GET http://localhost:8080/greet/{name}

Expected: The response to be Hello {name}
Actual: io.grpc.StatusRuntimeException: UNIMPLEMENTED

Important note: Implementing every other service type (blocking, bare gRPC, Mutiny impl base) works as expected.

Output of uname -a or ver

OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"

Output of java -version

openjdk version "11.0.12" 2021-07-20 OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7) OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.2.1.Final

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

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)

Additional information

No response

[quarkus-bot]

/cc @cescoffier, @michalszynkiewicz

[michalszynkiewicz]

@kristijan-rusu thank you for your report.
For now I can say that adding beans.xml to the project solves the problem. But I'm not sure what's the proper fix. I'll hope we'll be able to figure this out with @mkouba tomorrow

[cescoffier]

Wouldn't using the jandex plugin would fix it too?

[michalszynkiewicz]

@cescoffier it's not enough, we'll investigate with Martin tomorrow.

[mkouba]

Ok, it's a bit tricky here. You need to add the META-INF/beans.xml because the example-api artifact is not considered a bean archive and thus ignored when CDI beans are discovered. The generated jandex.idx is not enough, because the archive does not contain a class that has a bean defining annotation (e.g. scope), nor a qualifier annotation, nor an interceptor binding.

In fact, the scope annotation is added to the generated org.example.api.GreeterBean via an annotation transformer, but that's "too late".

I think that we should add the @GrpcService annotation to the generated GreeterBean. This way the archive will never be ignored and the bean is still registered only if needed (i.e. when the scope is added). I'll try to prepare a PR.

[mkouba]

I think that we should add the @GrpcService annotation to the generated GreeterBean.

Hm, this won't actually work. We don't ignore an archive that contains a qualifier definition (i.e. an annotation annotated with @Qualifier), not an archive that contains a class annotated with a qualifier.