|Re: [ecf-dev] help|
I notice a few things wrong with your client/remote service consumer...and I've put some inline comments...but before that I should ask...why (on the consumer) are you using the ECF remote services API *directly*? That is, with the OSGi remote services spec/standard, as well as the newly release remote services admin , it is quite possible to use the normal OSGi service access mechanisms (e.g. ServiceTracker, getServiceReference, declarative services, other injection frameworks, etc)...and not have to access ECF code at all. This is what several of the example consumers do (use ds, or ServiceTracker to get the local proxy to the remote service).
However, you should be able to use the ECF remote service API directly on the consumer...if you wish...so I'll provide comments to your code below...but I just wanted to point out that there are other ways.
One other thing I should mention, however...before commenting on your consumer code. The RSA specification (newly implemented in ECF 3.5) defines a discovery mechanism...and it also defines a file-based discovery...so that you can trigger the OSGi remote service discovery by defining an xml-file that provides meta-data about the remote service...in a standardized format called 'Endpoint Description Extender Format' (edef). There is now an example consumer that uses the edef file...and some wiki documentation of how to use this format . Note that in accord with the RSA spec, the edef file is read...triggering the remote service discovery...*when the bundle containing the edef is started*.
(e.g. On 3/21/2011 3:20 AM, ronen hamias wrote:
containerAdapter should not be null...as the next line will cause a NPE if it is. The r-osgi container should return a non-null containerAdapter with this code. If containerAdapter is null after the call to getAdapter, then something else is wrong.
GENERIC_SERVICE_HOST will not be correct...as you seem to be using the r-osgi provider (i.e. ecf.r_osgi.peer) on the host. For r-osgi, this should be something like:
"r-osgi://localhost:9268/" rather than GENERIC_SERVICE_HOST
Well, like I said above...there are several ways...including using the ECF remote services API as you try to do above...but there are simpler/easier ways (e.g. OSGi service access mechanisms) if you wish to use them. The various hello example bundles with 'consumer' in their name show different ways to do this...e.g. o.e.e.e.remoteservices.hello.consumer (ServiceTracker), o.e.e.e.remoteservices.hello.consumer.edef (edef format), o.e.e.e.remoteservices.hello.consumer.rs (ECF remote service api), o.e.e.e.remoteservices.hello.ds.consumer (declarative services). All of these consumers are as applicable in server environment as they are in client...as they have no UI.
Back to the top