[ecf-dev] work on osgi remote services spec

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Folks,

This week I'm working on implementing the OSGi remote services spec 
(chap 13).  Here's the ECF bug that's tracking this work:  
https://bugs.eclipse.org/bugs/show_bug.cgi?id=290446

One of the things that the new remote services spec does differently 
than RFC119 is that it introduces the concept of a 'configuration type'. 

In the spec, distribution providers specify configuration type names 
(i.e. Strings), that they understand...and when remote services are 
registered (via bundleContext.registerService), the configuration types 
can be specified.  If the configuration types specified by the remote 
service being registered match those exposed by a given provider, then 
that provider will be created/configured...and will be given an 
opportunity to distribute the service.

Happily, this matches ECF's IContainer/provider architecture very 
well...that is...we already have the equivalent of a configuration type 
name...in essence it's the name of the ECF provider/container 
factory...which uniquely identifies the provider (e.g. 
"ecf.generic.client" or "ecf.r-osgi.peer").  This string can be used to 
lookup a ContainerTypeDescription (meta-information about an IContainer, 
along with the provider-implemented IContainerInstantiator...which is 
responsible for implementing the IContainer construction)...and then 
IContainer instances can be created...optionally using other service 
properties to specify the container construction parameters.

One nice side effect about this is that with our implementation of the 
remote services spec, we can/will allow containers that don't already 
exist (at service registration time) to be dynamically 
constructed/configured to support a given remote service registration.  
This will make it unnecessary to create IContainer instances prior to 
doing service registration (but can rather take place lazily as part of 
remote service registration itself).

But to support configuration types, I think it's going to be best to add 
a method like the following to the core 
org.eclipse.ecf.core.ContainerTypeDescription class

   public String[] getSupportedConfigTypes()

Adding this method will allow providers to specify at runtime the config 
types that they support.

I've added this method and made the necessary additions to the ECF core 
code and the providers in my local workspace, but have not checked it in 
yet because there is a complication caused by the way that we provide 
the ECF core and filetransfer bundles to Eclipse.  Since we deploy our 
core bundles via Eclipse (for p2) and *do not* deploy these bundles as 
part of the ECF sdk, any use of this new code will need new versions of 
the ECF core bundles...and the existing Eclipse doesn't have this new 
ECF core code...so won't compile unless the latest ECF core bundles are 
present.  We'll see this first in our automated build...but everyone 
that has the ECF sdk source in their workspace will also need the 
org.eclipse.ecf core bundle to prevent from getting compile errors.

After I commit the addition, the fix for ECF committers and contributors 
(i.e. anyone that is working with the source code), is to simply load 
the latest org.eclipse.ecf project contents into the workspace.

After the addition is made, and our own build can build it properly (and 
I'll figure out with Ted and Markus how to get this going), then I will 
submit the new ECF core code to next week's platform/p2 integration 
build, and then if people wish they can get the 3.6 Eclipse integration 
build (with the new ECF core code) rather than have the new 
org.eclipse.ecf code in their workspace.

I won't commit the addition until Ted, Markus, and I figure out how to 
adjust our own build to not be broken by the addition, and will then 
make another announcement before commiting the changes to head.  Please 
ask any questions or make any comments on the bug

https://bugs.eclipse.org/bugs/show_bug.cgi?id=290446

Thanks,

Scott