Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] work on osgi remote services spec

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:

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



Back to the top