Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Is it possible to consume a remote OSGi/gRPC service with plain grpc-java? #6

Closed
eum2o opened this issue Mar 31, 2021 · 19 comments
Closed

Is it possible to consume a remote OSGi/gRPC service with plain grpc-java? #6

eum2o opened this issue Mar 31, 2021 · 19 comments

Comments

@eum2o
Copy link
Contributor

eum2o commented Mar 31, 2021 •
edited
Loading

For example I have a local Karaf instance on which I deployed the health service example (following the guide on https://github.com/ECF/grpc-RemoteServicesProvider):

karaf@root()> feature:list -i
Name                                  | Version | Required | State   | Repository                     | Description
--------------------------------------+---------+----------+---------+--------------------------------+--------------------------------------------------
...
ecf-rs-examples-grpc-healthcheck-api  | 1.3.2   |          | Started | ecf-remoteservices-grpc-1.3.2  | ECF Remote Services Grpc HealthCheck Example Serv
ecf-rs-examples-grpc-healthcheck-impl | 1.3.2   | x        | Started | ecf-remoteservices-grpc-1.3.2  | ECF Remote Services Grpc HealthCheck Example Serv
...

I then tried to consume the health check service using plain grpc-java. My consumer/client code looks as follows:

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import io.grpc.health.v1.HealthCheckRequest;
import io.grpc.health.v1.HealthCheckResponse;
import io.grpc.health.v1.HealthGrpc;

public class Main {

    public static void main(String[] args) {
	System.out.println("Hello I am a gRPC client");

	ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50002)
		.usePlaintext()
		.build();

	HealthGrpc.HealthBlockingStub client = HealthGrpc.newBlockingStub(channel);
	final HealthCheckResponse check = client.check(HealthCheckRequest.newBuilder()
		.build());
	System.out.println(check.getStatus());

	channel.shutdown();
    }
}

which leads to the following output:

Hello I am a gRPC client
Exception in thread "main" io.grpc.StatusRuntimeException: UNIMPLEMENTED: Method not found: grpc.health.v1.Health/Check
	at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:262)
	at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:243)
	at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:156)
	at io.grpc.health.v1.HealthGrpc$HealthBlockingStub.check(HealthGrpc.java:251)
	at grpc.java.course.client.Main.main(Main.java:19)

PS: If it's possible to consume OSGi/gRPC remote services outside the OSGi ecosystem, is it possible to activate gRPC server reflection on a Karaf instance? E.g. to get an overview of all gRPC services the Karaf instance provides?

(Btw thanks for that awesome feature. It would be awesome if you can reuse your OSGi services from plain java, e.g. by deploying them on Karaf and consuming them using grpc-java.)
@eum2o eum2o changed the title How to enable io.grpc.protobuf.services.ProtoReflectionService Is it possible to consume a remote OSGi/gRPC service from Non-OSGi Clients? Mar 31, 2021
@eum2o eum2o changed the title Is it possible to consume a remote OSGi/gRPC service from Non-OSGi Clients? Is it possible to consume a remote OSGi/gRPC service with plain grpc-java? Mar 31, 2021
@scottslewis
Copy link
Member

scottslewis commented Apr 1, 2021 •
edited
Loading

It was a surprise to me that your non-OSGi client (provided above) didn't work, so I took your program and modified:

package healthchecktest;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import io.grpc.health.v1.HealthCheckGrpc;
import io.grpc.health.v1.HealthCheckRequest;
import io.grpc.health.v1.HealthCheckResponse;

public class Main {

    public static void main(String[] args) {
	System.out.println("Hello I am a gRPC client");

	ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50002)
		.usePlaintext()
		.build();

	HealthCheckGrpc.HealthCheckBlockingStub client = HealthCheckGrpc.newBlockingStub(channel);
	final HealthCheckResponse check = client.check(HealthCheckRequest.newBuilder()
		.build());
	System.out.println(check.getStatus());

	channel.shutdown();
    }
}

Note that it's using the HealthCheckGrpc class (in org.eclipse.ecf.examples.provider.grpc.health.api project) rather than the HealthGrpc class from the original grpc example. I had to modify the package in the proto file (see o.e.e.examples.provider.grpc.health.api/src/main/proto/health.proto) and class naming conventions for the osgi code generation.

After fussing quite a lot with the classpath/modulepath for this example client, I was able to get it to run successfully against an OSGi-based server...exporting the HealthCheckService as per the org.eclipse.ecf.example.provider.grpc.health.impl bundle. I wasn't using Karaf for this test, but it was still an osgi server running and exporting the HealthCheckService via ECF remote service admin.

So...this use case is possible/currently supported! (non-OSGi grpc client with OSGi server exporting a remote service).

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

PS: If it's possible to consume OSGi/gRPC remote services outside the OSGi ecosystem, is it possible to activate gRPC server reflection on a Karaf instance? E.g. to get an overview of all gRPC services the Karaf instance provides?

Yes! This would be a very nice addition. I would be inclined to a) add grpc-services jar (and ProtoReflectionClass) to the ECF distribution provider, and b) make a few new gogo commands that would allow remote method calls to be made from the osgi gogo console.

I can't do this instantaneously, but I will try to work on it within a few days.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 1, 2021 •
edited
Loading

Note that it's using the HealthCheckGrpc class (in org.eclipse.ecf.examples.provider.grpc.health.api project) rather than the HealthGrpc class

Ah! By using HealthCheckGrpc it now works fine for me, too (without any other changes). Thanks a lot for the fast reply!

So...this use case is possible/currently supported! (non-OSGi grpc client with OSGi server exporting a remote service).

So you basically can consume OSGi remote services with any language supported by gRPC. You only need to download the .proto file, generate the sources and start coding. I think this is huge!

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

Sure thing! You could write it yourself within seconds I guess - but I think providing an example in this repository and explicitly documenting this feature/use case is a good idea. In fact, for me the main use case for using grpc-RemoteServicesProvider is to connect OSGi services with the non-OSGi-ecosystem. I don't know what's the benefit of consuming an gRPC remote service with an OSGi client. I would think that you can simply use a usual OSGi remote service (without the gRPC stuff). But I am not deep into this. There might be use cases I don't know or understand.

I would be inclined to a) add grpc-services jar (and ProtoReflectionClass) to the ECF distribution provider, and b) make a few new gogo commands that would allow remote method calls to be made from the osgi gogo console

Sounds great (especially a) for me in personal). Take your time.

@scottslewis
Copy link
Member

> So you basically can consume OSGi remote services with [any language supported by gRPC](https://grpc.io/docs/languages/). You only need to download the .proto file, generate the sources and start coding. I think this is huge!

I agree this is very cool. If you do any experimenting with other languages please consider contributing them back (for healthcheck) and I will add to this (or new) repo so that it's easier for people to give a try.

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

Sure thing! You could write it yourself within seconds I guess - but I think providing an example in this repository and explicitly documenting this feature/use case is a good idea. In fact, for me the main use case for using grpc-RemoteServicesProvider is to connect OSGi services with the non-OSGi-ecosystem. I don't know what's the benefit of consuming an gRPC remote service with an OSGi client.

A common use case with other providers is Eclipse (and Eclipse RCP apps) as OSGi clients. I don't see a reason why (e.g.) existing grpc services (osgi or not) might want to have such OSGi clients also. But...nice thing is this is supported as well.

@scottslewis
Copy link
Member

Hi Martin. It seems like it's going to be pretty easy to setup the ProtoReflectionService in the ECF grpc distribution provider. Actually I'm ready to try it out locally but I need the grpc_cli tool...and the grpc team doesn't distribute binaries for grpc_cli....and I don't currently have everything setup to build it on my win64 system. Would you happen to have a built grpc_cli.exe for win64? If so could you allow me to download it and use it for testing? Thanks.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 4, 2021 •
edited
Loading

Unfortunately, I don't have a built grpc_cli tool available. In fact, I tried to build it on my win64 system following their instructions but sadly I didn't manage to succeed (make throws errors due to missing files but don't wanna bother you with details).

However, if you ask for grpc_cli to test the reflection service, let me recommend you Evans:

For example if you have a gRPC server running on port 50002 you can run

evans -r -p 50002

If no error is printed, you already have verified that the reflection service is working. After that, in the Evans console, you can e.g. type*

show service

which, in case the HealthCheck service is deployed/distributed, should lead to an output like the following:

+-------------+-------------+--------------------+---------------------+
|   SERVICE   |     RPC     |    REQUEST TYPE    |    RESPONSE TYPE    |
+-------------+-------------+--------------------+---------------------+
| HealthCheck | Check       | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchServer | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchClient | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchBidi   | HealthCheckRequest | HealthCheckResponse |
+-------------+-------------+--------------------+---------------------+

After that you can type service HealthCheck led by call Check to call the check method for example.

[*]: show service will only work if there is just 1 package (e.g. io.grpc.health.v1 on your gRPC server). If there are multiple packages in your test instance, you would first have to type show package and then go into your HealthCheck package, e.g. with something like package io.grpc.health.v1. After that show service lists all services in that package.

@scottslewis
Copy link
Member

Unfortunately, I don't have a built grpc_cli tool available. In fact, I tried to build it on my win64 system following their instructions but sadly I didn't manage to succeed (make throws errors due to missing files but don't wanna bother you with details).

However, if you ask for grpc_cli to test the reflection service, let me recommend you Evans:

Thanks...Evans seems pretty cool.

I've updated the grpc distribution provider and target platform to use grpc 1.36.1 (has ProtoReflectionService), and I've been able to add and successfully test the modified disttribution provider (GrpcHostContainer class) with the ProtoReflectionService via Evans! It works pretty nicely with the HealthCheck example as you describe.

I update the grpc distribution provider features from 1.3.2 -> 1.4.0. I would like to do a little more testing before doing the 1.4.0 release, however. I would appreciated it if you would give it a try. I've made it so that the proto reflection service can be turned on via the following system (or service) property: -Decf.grpc.server.protoReflectionService=true. It's default is off (false).

You can also specify this service property: ecf.grpc.server.protoReflectionService=true for an exported service to turn it on as well.

Please let me know if/when you have a chance to try it and I'll get 1.4.0 released.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 5, 2021 •
edited
Loading

I performed some happy day test scenario and it works fine!

How I set up the test environment

I am mentioning this especially to see if this is the way you expected me to test or if I am missing something. I first was looking for a build I can use for testing (some v1.4.0 JAR). But I think I had to build it myself (which generally is no problem - I just wasn't sure if this is the way to go - e.g. should I have used the launch configs?).

  1. I cloned your repo
  2. I locally built bundles/org.eclipse.ecf.provider.grpc with mvn clean install
  3. I locally modified build/karaf-features.xml:
    • Replaced <bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.provider.grpc_1.3.0.202009261541.jar with <bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc
    • Replaced versions 1.3.3 and 1.3.2 with 1.4.0
  4. Locally started Karaf and in the console I ran:
    • repo-add file:/pathToClonedRepo/build/karaf-features.xml
    • feature:install -v ecf-rs-distribution-grpc
    • feature:list -i to verify v1.4.0 of ecf-rs-distribution-grpc was installed
    • <Install my own service with the ecf.grpc.server.protoReflectionService property set to true>

Test Result

I now can use Evans to discover all gRPC services that are provided by my Kraraf instance. Calling them works fine, too (tested a unary call only). This is a great feature, thanks for that!

During testing I was wondering if it could be useful to create a dedicated bundle providing the ProtoReflectionService instead of adding it when org.eclipse.ecf.provider.grpc is started. This way you could start/stop this dedicated bundle in Karaf to enable/disable gRPC reflection on demand. What do you think?

@scottslewis
Copy link
Member

a unary call only). This is a great feature, thanks for that!

You are welcome.

During testing I was wondering if it could be useful to create a dedicated bundle providing the ProtoReflectionService instead of adding it when org.eclipse.ecf.provider.grpc is started. This way you could start/stop this dedicated bundle in Karaf to enable/disable gRPC reflection on demand. What do you think?

I did add a new bundle: org.eclipse.ecf.provider.grpc.console. This bundle extends the gogo osgi console by adding new commands for dynamically controlling the ProtoReflectionService on 1 or more GRPCHostContainer instances. See the commit notes on this commit:

0751118

I'm pretty happy with it this way...it allows custom defaults for each container instance (via either system property or service property...which is still there), and now with the gogo commands the protoreflectionservice can be added or removed dynamically at any time. Further, the console can be left out entirely...if it's not needed for deployment.

I still need to add the new bundle to parts of the build (e.g. the karaf-features.xml).

Let me know what you think...and if you like I'll get 1.4.0 out.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 6, 2021 •
edited
Loading

0751118

This is nice. If the commands are working as described I think it makes the reflection feature complete and it's ready to release from my perspective.

Unfortunately I didn't manage to test it. I locally built org.eclipse.ecf.provider.grpc and org.eclipse.ecf.provider.grpc.console (for the console bundle I had to add a dependency to org.eclipse.osgi.services, otherwise the tycho-compiler-plugin complains about unresolveable org.osgi imports (@component, @reference)). After that I added the following repository to karaf (repo-add file:/path..):

<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0" name="ecf-rs-distribution-grpc-1.4.0">

    <repository>http://download.eclipse.org/rt/ecf/RELEASE/site.p2/karaf-features.xml</repository>

<feature name="ecf-rs-distribution-grpc-support" version="1.4.0"
	description="ECF Remote Services Grpc Distribution Provider Support. See https://github.com/ECF/grpc-RemoteServicesProvider">
	<feature>ecf-rs-rsa</feature>
	<feature>ecf-rs-console</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.gson_2.7.0.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.guava_26.0.0.android.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.guava.failureaccess_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.protobuf_4.0.0.rc-2.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.salesforce.servicelibs.reactive-grpc-common_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.salesforce.servicelibs.rxgrpc-stub_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.buffer_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-http_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-http2_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-socks_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.common_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.handler_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.handler-proxy_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.resolver_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.transport_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.reactivex.rxjava2.rxjava_2.2.19.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.reactivestreams.reactive-streams_1.0.3.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.jsr-305_3.0.2.jar</bundle>
	</feature>
	
	<feature name="ecf-rs-distribution-grpc"
		version="1.4.0"
		description="ECF Remote Services Grpc Distribution Provider. See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature>ecf-rs-distribution-grpc-support</feature>
		<bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc
		</bundle>
		<bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc.console
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-api" version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service API.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-distribution-grpc</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.api_1.2.0.202009261541.jar
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-impl"
		version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service Host.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-examples-grpc-healthcheck-api</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.impl_1.1.0.202009261541.jar
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-consumer"
		version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service Consumer.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-examples-grpc-healthcheck-api</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.consumer_1.1.0.202009261541.jar
		</bundle>
	</feature>

</features>

The command feature:install -v ecf-rs-distribution-grpc then leads to the following error:

Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=ecf-rs-distribution-grpc; type=karaf.feature; version="[1.4.0,1.4.0]"; filter:="(&(osgi.identity=ecf-rs-distribution-grpc)(type=karaf.feature)(version>=1.4.0)(version<=1.4.0))" [caused by: Unable to resolve ecf-rs-distribution-grpc/1.4.0: missing requirement [ecf-rs-distribution-grpc/1.4.0] osgi.identity; osgi.identity=org.eclipse.ecf.provider.grpc.console; type=osgi.bundle; version="[1.0.0.v20210406-0719,1.0.0.v20210406-0719]"; resolution:=mandatory [caused by: Unable to resolve org.eclipse.ecf.provider.grpc.console/1.0.0.v20210406-0719: missing requirement [org.eclipse.ecf.provider.grpc.console/1.0.0.v20210406-0719] osgi.wiring.bundle; osgi.wiring.bundle=org.apache.felix.gogo.runtime; bundle-version=1.1.0; filter:="(&(osgi.wiring.bundle=org.apache.felix.gogo.runtime)(bundle-version>=1.1.0))"]]

Apparently, I lack the org.apache.felix.gogo.runtime bundle in my Karaf instance. I am a Karaf newbie but from my understanding, Karaf uses/builds upon the gogo console so I would expect the gogo runtime already pre-installed. Nevertheless, I tried to fix this problem by installing the features shell and shell-compat. But installing these hasn't fixed the problem. Can you give me a hint what I'm doing wrong or where I can get the gogo runtime bundle from?

I am using Apache Karaf (4.3.0).

@scottslewis
Copy link
Member

scottslewis commented Apr 6, 2021 •
edited
Loading

> > Apparently, I lack the `org.apache.felix.gogo.runtime` bundle in my Karaf instance. I am a Karaf newbie but from my understanding, Karaf uses/builds upon the gogo console so I would expect the gogo runtime already pre-installed. Nevertheless, I tried to fix this problem by installing the features `shell` and `shell-compat`. But installing these hasn't fixed the problem. Can you give me a hint what I'm doing wrong or where I can get the gogo runtime bundle from? > > I am using Apache Karaf (4.3.0).

--

For Karaf, I imported the wrong thing in org.eclipse.ecf.provider.grpc.console. It worked for my testing in Eclipse/Equinox (localhost) because Eclipse uses gogo directly, while Karaf has it's own implementation. I've fixed so that it should work for both and pushed the fix to master.

Your testing is not wasted, however...please just consider this release testing for 1.4.0. Thanks (and inadvance) for that as it's definitely speeding up the release process.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 6, 2021 •
edited
Loading

At this moment the latest commit is dd03903.

  • ✅ The console bundle can now be compiled with tycho
  • ✅ Both org.eclipse.ecf.provider.grpc and org.eclipse.ecf.provider.grpc.console can be installed to Karaf (all dependencies found)
  • ✅ Reflection service can now be activated/deactivated on demand (tested all 4 commands and they work as specified - //edit: haven't tested the optional parameters, tho)

Thanks again for all the cool features! For my use case this is everything I need. I am looking forward to the 1.4 release :)

@scottslewis
Copy link
Member

scottslewis commented Apr 6, 2021 •
edited
Loading

Thanks for the testing and review.

In preparation for release of 1.4, I've created a new issue to detail this new protoReflectionService feature and begin documentation:

#9

If you have things to add (other things I've forgotten about this feature) or other issues that you want in 1.4 please add to that issue or create new issue as appropriate.

Thanks again for the idea for this. I think it will be a nice addition for debugging and testing...especially with non OSGi consumers.

I also created this new issue to capture the desire for examples of non-OSGi consumers (java and other langs) for grpc-exported OSGi Remote Service.

#10

@scottslewis
Copy link
Member

I'm going to close this issue in favor of these others. Again...thanks.

@scottslewis
Copy link
Member

Hi Martin.

I've used your coding work to add a new java app for a healthcheck consumer as described here:

#10 (comment)

Since this contains your work (and name in copyright notice) I would like your review and explicit approval.

Thanksinadvance.

@scottslewis
Copy link
Member

Hi Martin.

Wanted to let you know that I've built and released version 1.4.0 of the grpc remote services provider.

I would appreciate it if you could try out the various parts that are relevant to you (karaf installation, p2 repo/eclipse install?, java applicaiton).

I have not updated the Readme.md on home page for repo...my intention is to write up the ProtoReflectionService (e.g. document new gogo commands and put on separate wiki page...and link to from Readme.md), Describe the availability (in source) of the java-app example consumer, document the move to 1.36.1 of grpc. I'm also thinking of describing the use of of bndtools to generate (in Eclipse) the java source from protofile...in addition to the maven plugin code generation in the healthcheck example).

If you have the availability and inclination, I would appreciate any contributions of documentation for these features. It would be good to have a perspective that is not as polluted as my own...to improve usability.

Thanks.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 10, 2021 •
edited
Loading

Hi Scott. I'm glad to hear about the release. I tested my use cases. Here's the protocol (tl;dr: Consuming with plain Java and the reflection service work fine.)

Server Side (Karaf)

(Using Karaf 4.3.0)

  • I started with a "fresh" Karaf instance (deleted the $KARAF_HOME/data folder)
    • In the $KARAF_HOME/karaf.bat file I appended -Decf.grpc.server.protoReflectionService=true to the DEFAULT_JAVA_OPTS variable (although the correct way probably would be to set the EXTRA_JAVA_OPTS or JAVA_OPTS variable before starting Karaf) to activate the reflection service
    • repo-add https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/karaf-features.xml
    • feature:install -v ecf-rs-distribution-grpc
      • ⚠️ Apparently at least Java 9 is required now because some dependency requires it (I didn't note which dependency in particular). This wasn't the case before. But should be not big deal as far as I can judge. I switched from Java 8 to Java 11 at this point.
    • ✅ Verified that ecf-rs-distribution-grpc v1.4.0 is installed
    • feature:install -v ecf-rs-examples-grpc-healthcheck-impl
    • ✅ Verified that the reflection service related commands documented on 0751118 work as specified (without optional parameters) using Evans
      • ⚠️ It could be helpful when the togglereflection command prints the current state of the reflections service (active or inactive). Currently it prints the very same text no matter if reflection is activated or deactivated.

Client Side (Example Java App in Eclipse)

(Using Eclipse 2021-03)

  • I cloned this repo and imported the following projects into my workspace:
    • healthcheck.consumer.javaapp because I want to test consumption of the HealthCheck service installed to Karaf
      • ❌ There are two errors: 1.) The code does not compile and 2.) the referenced src folder /test does not exist.
        • I fixed this by 1.) adding a dependency to the .api project and 2.) removing the /test src folder from the .classpath
    • org.eclipse.ecf.examples.provider.grpc.health.api because I need it for the .javaapp project to compile
  • Installed the "ECF Grcp Remote Services Provider Feature" from the http://raw.githubusercontent.com/ECF/grpc- RemoteServicesProvider/master/build updatesite to satisfy the dependencies of the .api project
  • ✅ Verified that the .javaapp project can consume the HealthCheck service by running the main method.

Test Summary

It works fine. With the latest 1.4.0 release of ecf-rs-distribution-grpc it's (still) possible to deploy OSGi remote services generated with the grpc-osgi-generator. It supports gRPC server reflection. Consuming the remote service with plain Java (still) works fine. The problems with the .javaapp project (see ❌) should probably be fixed, though.

(I also have a little example project (which is duplicating your example a little but it's more specific to my particular needs) - and it still works fine with v1.4.0)

Describe the availability (in source) of the java-app example consumer

Yes, good. When doing so, you should consider mentioning that you have to install the "ECF Grcp Remote Services Provider Feature" from the http://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build updatesite. If someone wants to give the example java client a try, he/she will need to import the .api project, too. And to satisfy its dependencies, the mentioned feature needs to be installed in Eclipse. The alternative would be to import the org.eclipse.ecf.provider.grpc project into the workspace but IMHO one shouldn't need to import the productive code into the workspace in order to test the example code (might be a matter of taste, tho).

I would appreciate any contributions of documentation

I am not averse to contribute documentation or review your documentation. However, I have never contributed to open source projects. I might lack some knowledge or best practices how to write guides. But if you have something particular, where you think I can support you, feel free to contact me. Currently I wouldn't know where to start/what to document (this might change when I/we actually start using OSGi/gRPC remote services - then I might come up with ideas and interesting use cases - for now I feel like I have very little experience - I just followed your examples without experimenting too much).

Also I want to give other languages that are supported by gRPC a try (e.g. consuming your HealthCheck service). As soon as I am doing this, I'd share the code with you. But I can't give a due date yet. There's are many other things I have to try out (like the bndtools workspace support just to mention one).

@scottslewis
Copy link
Member

> * `repo-add https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/karaf-features.xml` > * `feature:install -v ecf-rs-distribution-grpc` > > * ⚠️ Apparently at least Java 9 is required now because some dependency requires it (I didn't note which dependency in particular). This wasn't the case before. But should be not big deal as far as I can judge. I switched from Java 8 to Java 11 at this point.

Yes. As it turns out com.google.json (of new version) requires Java 10 (I think) and grpc 1.36.1 uses it so...

  * ✅ Verified that `ecf-rs-distribution-grpc` v1.4.0 is installed
  * `feature:install -v ecf-rs-examples-grpc-healthcheck-impl`
  * ✅ Verified that the reflection service related commands documented on [0751118](https://github.com/ECF/grpc-RemoteServicesProvider/commit/07511182386891d76e039f65a96ccf5f8f758906) work as specified (without optional parameters) using Evans
    
    * ⚠️ It could be helpful when the `togglereflection` command prints the current state of the reflections service (active or inactive). Currently it prints the very same text no matter if reflection is activated or deactivated.

I'll look at this. I think there might be some bug in the karaf console impl as this works as desired in gogo console. In any event, I'll look at it.

Client Side (Example Java App in Eclipse)

(Using Eclipse 2021-03)

* I cloned this repo and imported the following projects into my workspace:
  
  * `healthcheck.consumer.javaapp` because I want to test consumption of the HealthCheck service installed to Karaf
    
    * ❌ There are two errors: 1.) The code does not compile and 2.) the referenced src folder `/test` does not exist.
      
      * I fixed this by 1.) adding a dependency to the .api project and 2.) removing the `/test` src folder from the `.classpath`

I've removed test from classpath and added dependency to api project and pushed.

@eum2o
Copy link
Contributor Author

eum2o commented Apr 10, 2021 •
edited
Loading

as this works as desired in gogo console

Ah, ok. Maybe I should have told you earlier when I tested it the first time. Here's what I see in Karaf:

image

(Nothing crucial from my perspective, no hurries)

@scottslewis scottslewis mentioned this issue Apr 10, 2021
Closed
@scottslewis
Copy link
Member

Yeah...this is some issue with karaf's console impl. I've created this new issue for it. Thanks.

#11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@scottslewis @eum2o