wildfly-extras/wildfly-grpc-feature-pack

WildFly gRPC feature pack

wildfly-grpc-feature-pack's Issues

Enhance Elytron SSL context integration

Remove the SSL configuration stuff in favor of using the org.wildfly.security.ssl-context capability from the Elytron subsystem. This will give us a single attribute to set rather than trying to build our own SSLContext.

Grpc feature-pack can't be used with WildFly 31 Beta1

When trying to provision it we got the following missing module:
org.wildfly.extras.grpc:wildfly-grpc-feature-pack:0.1.2.Final package io.grpc
Failed to resolve package com.squareup.okhttp3 in wildfly@maven(org.jboss.universe:community-universe):current#31.0.0.Beta1

Add support for socket bindings

Remove the server-host and server-port attributes in favor of using a socket-binding.

Build error when trying to launch the examples

Hi, I get the following error when trying to launch the examples. It seems the grpc artifacts are missing in the public repo.

The following artifacts could not be resolved: org.wildfly.extras.grpc:wildfly-grpc-api:jar:0.0.1, org.wildfly.extras.grpc:wildfly-grpc-examples-helloworld-proto:jar:0.0.1: Could not find artifact org.wildfly.extras.grpc:wildfly-grpc-api:jar:0.0.1 in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/_)

Use the version of OpenJFX that is associated with the compiler version

In the chat example OpenJFX is used. It's been updated by dependabot to version 20 which won't work with Java 11. We should use the version associated with the current minimum required Java version.

With this, we should enable a profile where we build with the examples and possibly the documentation too for CI.

Clarify service registration and deployments

I think we need to consider how services are added. If multiple applications are deployed, only the first deployment started registers its services with the gRPC server. I'm not sure if there is some variant of a mutable server, but if not, it will take some thought on how this could be done. I don't think we want to stop and restart a server for every deployment being processed. It's experimental, but we might need something like this https://grpc.github.io/grpc-java/javadoc/io/grpc/util/MutableHandlerRegistry.html.

Another thing to consider along these lines is if there are any possible security issues around registering services from different deployments on the same gRPC server. Again, I'd need to read more here to understand how this works. However, we don't want to allow deploymentA to see services from deploymentB.

Migrate to use the new org.wildfly.tools:wildfly-parent for the parent POM

This new parent includes the formatter plugin and a standard Eclipse Formatter configuration.

https://github.com/wildfly/wildfly-dev-tools

Migrate the example standalone XML files to use either YAML configuration files or CLI to provision a server

Currently in the examples a standalone.xml.* file is copied from the ssl directory. We should use either CLI to configure a server or use YAML to overlay the configure. This allows the configuration to be up to date with the version of WildFly we're using instead of a static version set to a specific WildFly release.

Refactor the GrpcServerService and subsystem add operation

The GrpcServerService does a lot of work that should likely be done in the subsystem add OperationStepHandler. The subsystem details should be hidden from the service and the deployment unit processor. Also add the correct capabilities to for the attributes which required capabilities.

Add a new capability for the gRPC subsystem itself.

Currently the gRPC subsystem won't be reloaded after the gRPC based project is redeployed

Detail description here:

• resteasy/resteasy.github.io#129 (comment)

Add the `io.grpc` modulea as it will be removed in WildFly

WildFly has the io.grpc modulea marked as private. This modulea is not used in WildFly and will be removed, see WFLY-17797.