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.
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
--
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
|