New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggested changes for supporting OSGi Remote Services #6980
Conversation
methods in java_generator.h/.cpp for generating two new types: GenerateOSGiService - Generates interface class(s) (in java_package directory) that has the same name as the rpc declaration in the protofile. For example: service HealthCheck { // If the requested service is unknown, the call will fail with status // NOT_FOUND. rpc check(HealthCheckRequest) returns (HealthCheckResponse); } would generate a HealthCheck service interface class: package io.grpc.health.v1; public interface HealthCheck { public HealthCheckResponse check(HealthCheckRequest request); } Note that only blocking method calls (not streaming) are included in the interface declaration. GenerateOSGiAbstractImplService generates an abstract impl class that implements the (e.g.) HealthCheck interface, with naming convention Abstract<service name>Impl: package io.grpc.health.v1; import io.grpc.stub.StreamObserver; public abstract class AbstractHealthCheckImpl extends HealthCheckGrpc.HealthCheckImplBase implements HealthCheck { public abstract HealthCheckResponse check(HealthCheckRequest request); public void check(HealthCheckRequest request, StreamObserver<HealthCheckResponse> responseObserver) { responseObserver.onNext(check(request)); responseObserver.onCompleted(); } } Note that the impl of the grcp check/2 method calls the service interface method check/1. With the service interface method and the abstract service impl class, it is easy for a remote service to be created as all that is needed is to provide implementation for check/1 method in subclass. Consumers of the remote service use the interface only.
|
in service interface and in abstractserviceimpl class.
and abstract service interface impl
These grpc-java protobuf plugin changes result in two new java classes: and Interface class (with suffix Intf) and an abstract impl of this interface: AbstractIntfImlpl. Frome what I can tell the travice continuous integration build above fails on tests because of these git errors associated with the new java files created by the modified plugin: https://travis-ci.org/github/grpc/grpc-java/jobs/679881915 $ test -z "$(git status --porcelain)" || (git status && echo Error Working directory is not clean. Forget to commit generated files? && false) HEAD detached at FETCH_HEAD Untracked files: (use "git add ..." to include in what will be committed)
nothing added to commit but untracked files present (use "git add" to track) Error Working directory is not clean. Forget to commit generated files? The command "test -z "$(git status --porcelain)" || (git status && echo Error Working directory is not clean. Forget to commit generated files? && false)" failed and exited with 1 during . Your build has been stopped. |
This was discussed in #6981, and we weren't ready to have interfaces in our generated code. @scottslewis split this out into a separate plugin at https://github.com/ECF/grpc-osgi-generator |
Added methods in java_generator.h/.cpp for generating two new types:
GenerateOSGiService - Generates interface class(s) (in java_package
directory) that has the same name as the rpc declaration in the
protofile. For example:
along with all the other classes normally generated by grcp plugin it would generate a HealthCheck service interface class:
Note that only blocking method calls (not streaming) are included in the
interface.
GenerateOSGiAbstractImplService generates an abstract impl class that
implements the (e.g.) HealthCheck interface, with naming convention
AbstractImpl:
Note that the impl of the grcp check/2 method calls the service
interface method check/1.
With the service interface method and the abstract service impl class,
it is easy for a remote service to be created as all that is needed is
to provide implementation for check/1 method in subclass. Consumers of
the remote service use the interface only.