[WFLY-15495] Add gRPC to WildFly via a new subsystem.#797
[WFLY-15495] Add gRPC to WildFly via a new subsystem.#797jamezp wants to merge 1 commit intowildfly:mainfrom
Conversation
|
The original analysis doc was #438. |
| This is a new feature and subsystem. However, it is **not compatible** with the existing wildfly-extras gRPC feature | ||
| pack (https://github.com/wildfly-extras/wildfly-grpc-feature-pack). The new subsystem uses a fundamentally different | ||
| architecture: | ||
|
|
||
| * **Old feature pack:** Runs a standalone Netty server on a separate port | ||
| * **New subsystem:** Integrates with Undertow's HTTP/2 listeners on the default port (8080) |
There was a problem hiding this comment.
I think there was a discussion somewhere in Zulip, the existing grpc FP is still in a low stability, so I don't think there is anything that precludes us from rewriting it into implementing this proposal in there. Certainly, this approach has certain benefits (no need to manage another module in WF) and disadvantages (alignment, etc).
Perhaps we can document that decision here too.
| # Provide the GitHub ids of the feature team members, organized by role. | ||
| # Provide a single id for the 'assignee' role. Use a YAML list for the 'sme' and | ||
| # 'outside-perspective' roles, even if there is only one person in a role. | ||
| feature-team: | ||
| developer: jamezp | ||
| sme: | ||
| - | ||
| outside-perspective: | ||
| - |
There was a problem hiding this comment.
Just for book keeping this section needs people here :-)
There was a problem hiding this comment.
Yes, I'm awaiting volunteers :)
| separate port. This proposal aims to integrate gRPC as a first-class citizen within the WildFly, allowing gRPC services | ||
| to be deployed as CDI beans and served over the existing Undertow HTTP/2 listeners. |
There was a problem hiding this comment.
In the current grpc feature pack we have org.wildfly.extension.grpc.WildFlyGrpcDeploymentRegistry that allows registration of services programatically. Is the plan to no longer support this givne there is only mention of the CDI beans support?
There was a problem hiding this comment.
Correct. The plan is to look for implementations of io.grpc.BindableService and register those. There will be no need to register anything manually.
There was a problem hiding this comment.
Well, I should clarify. We will still be keeping a registry of these, but we will also be registering these as CDI. At least that is what my current implementation does. We'll see if I need to keep that reference or not.
There was a problem hiding this comment.
@jamezp The reason I bring this up is because I believe that the current GRPS FP might be doing this in a problematic way, looking here
https://github.com/wildfly-extras/wildfly-grpc-feature-pack/blob/v0.1.16/subsystem/src/main/java/org/wildfly/extension/grpc/deployment/GrpcDeploymentProcessor.java#L55
this is consulting the jandex index, which is problematic as that index will only include the deployment classes, but never any classes provided by the server. The solution for that is to use the WildFlyGrpcDeploymentRegistry programatically.
There was a problem hiding this comment.
@rhusar I'm not sure we want to provide support for gRPC services outside of the deployment. At least not in this first iteration.
https://issues.redhat.com/browse/WFLY-15495 Signed-off-by: James R. Perkins <jperkins@ibm.com>
github-actions
bot
added
stability-level/default
2 participants
https://issues.redhat.com/browse/WFLY-15495
resolves #796