Actually, you had pointed out the DS services earlier, but I had been focused on the website tutorials. I will look at the DS tutorials more closely now, as you had outlined.
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
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
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).
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?
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():
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.
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.