Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Validating RemoteServices Setup
On 9/20/2016 1:23 PM, Ramachandran K. Narayanan wrote:
Hello ECF-Dev,

I had followed the tutorial at

to make modifications to carry over an existing local OSGi setup to a Remote OSGi setup. But it doesn't look like the remote services changes are having an effect and I was wondering how I could validate the changes:

1) Based on the steps in the HelloHostApplication example:

// add ECF service property specifying container factory args
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I set containerId to "r-osgi://localhost:9280". But when I start this up, I don't see any service listening on port 9280 (using netstat). Is this expected or should I have to use port 9278?

r-osgi is unique as a provider in that you have to also set a system property named  ch.ethz.iks.r_osgi.port

See here for information:  http://wiki.eclipse.org/R-OSGi_Properties

The reason this is so is because rosgi predates the OSGi RSA spec and it defined it's own default port (9278) independently from  any notion of the container id.  So it has to be set with *both* the system property and the id set to the same desired port number (in your case 9280).

Rather than
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I would suggest using the standard OSGi service properties:

// This property specifies that you want to export all the service interfaces for your service

props.put("service.exported.interfaces","*");
// This property specifies that you wish to use the ecf.r_osgi.peer provider
props.put("service.exported.configs", "ecf.r_osgi.peer");
// This sends the value r-osgi://localhost:9280 for the key 'id' to the ECF r_osgi container
props.put("ecf.r_osgi.peer.id","r-osgi://localhost:9280");

Notice that ecf.r_osgi.peer.id is just the config with '.id' on the end.   This is the RSA-standard way of sending config information (in this case the id) into the provider.   Since this was introduced with ECF supporting RSA 1.0, ECF has a non-standard way of doing the same thing (container factory arguments), but it's better to use the RSA-standard approach if possible.


When I try this directly in the examples code, I get an error on the consumer side as it seems to expect port 9278.

Yes it will default to 9278 unless set by the ch.ethz.iks.r_osgi.port system property.


2) Also, why should localhost be specified in the containerId? After all, won't the Host Application always run on its "localhost" and would specifying a different host make sense?

3) On the Consumer side, the tutorial says:

getContainerFactory().createContainer(containerType);
helloServiceTracker = new ServiceTracker(bundleContext,createRemoteFilter(), this);
helloServiceTracker.open();

Note that the remote service can be accessed in a variety of ways...e.g. by using a ServiceTracker (as above), by using the BundleContext.getServiceReference methods, or injection via declarative services.

So instead of ServiceTracker, could I just do getServiceReference after the createContainer call?

Yes, although I would highly recommend using either a ServiceTracker or DS (preferably DS), as DS makes things much much simpler.

In the example code for the ServiceTracker, it also creates a filter via createRemoteFilter():

    private Filter createRemoteFilter() throws InvalidSyntaxException {
        return context.createFilter("(&("
                + org.osgi.framework.Constants.OBJECTCLASS + "="
                + IHello.class.getName() + ")(" + SERVICE_IMPORTED + "=*))");
    }

With DS, the filter is entirely unnecessary.  

My apologies...this tutorial should have been updated to emphasize using DS (and there are example projects in the repo that do this).

I tried it with the HelloHostApplication and Consumer examples using the (zeroconf, r-osgi) and (zookeeper, r-osgi) configurations (for both Host and Consumer) but it doesn't seem to work.

4) Is the createContainer call also necessary? I commented it out in the examples and didn't see any errors. I guess the example launch configurations are already creating a container and we still need it for more general cases.

You are right that it's not actually necessary any longer, but this is another old remnant of a pre-RSA....that I should remove.


Thanks for your help.

Sure.   If you can, please use DS both for local and remote services (both registration/export and import/injection).   It makes things oh so much easier.   There are examples and tutorials that do this...one here:  http://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service  and another example here:  https://github.com/ECF/enrouteEvalExampleRemoteService   that uses DS for both registration (host) and consumer.

I should have pointed this out to you previously.   My apologies about that, and that the old tutorials (IHello service) now unnecessary cruft that should be removed/cleaned up with RSA and DS both on the scene.

Scott



Regards,
Ramachandran


--
Ramachandran K. Narayanan
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top