Bugzilla – Full Text Bug Listing
| Summary: | [remotesvcs] Implement OSGi 4.2 remote services spec | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Scott Lewis <slewis> |
| Component: | ecf.remoteservices | Assignee: | Scott Lewis <slewis> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bugs.eclipse.org, remy.suen |
| Version: | 3.0.0 | Keywords: | plan |
| Target Milestone: | 3.2.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Scott Lewis
Adding plan keyword for inclusion into ECF plan document Assigning to myself/Scott. I've begun this effort...by adding the service property definitions from OSGi-4.2 draft specification (20090707) to org.eclipse.ecf.osgi.services.distribution.IDistributionConstants class. I will continue work on implementation over the next week. Update: I've just removed the RFC119 distribution classes: org.osgi.services.distribution.DistributionConstants and DistributionProvider from the org.eclipse.ecf.osgi.service bundle. This bundle previously provided access to the RFC119-specified classes. Since there are no RFC119 classes in the new remote services spec, these classes have to be removed. Next up for removal/elimination are RFC119 discovery classes (i.e. org.osgi.services.discovery.*). They are not long for this world. See here for the latest/final version of 4.2 spec (see chapter 13 in compendium...i.e. r4.cmpn.pdf): http://www.osgi.org/Download/Release4V42 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 this bug. (In reply to comment #5) > 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. Just an idea but why not add a new subclass like RemoteContainerTypeDescription to ContainerTypeDescription as well as something like IRemoteContainerInstantiator to a != org.eclipse.ecf bundle to separate the remote service implementation from the rest of ECF. The benefits are: A) Don't have to implement getSupportedConfigTypes() in all the containers that have nothing to with OSGi remote services. (most containers return null in getSupportedIntents()). B) won't have to deal with p2/build inclusion. A2) If separating RemoteContainerDescriptions from local ContainerDescriptions does not make sense, we should at least at an (abstract) superclass to all ContainerInstantiators that returns null on their behalf. (In reply to comment #6) <stuff deleted> > > Just an idea but why not add a new subclass like RemoteContainerTypeDescription > to ContainerTypeDescription as well as something like > IRemoteContainerInstantiator to a != org.eclipse.ecf bundle to separate the > remote service implementation from the rest of ECF. I agree this separation seems desirable...but the main problem is that ContainerTypeDescription actually just turns around and calls IContainerInstantiator to get the container meta-data (at runtime)...and RemoteContainerTypeDescription (if introduced) would have to do similarly...and so a new method IContainerInstantiator.getSupportedConfigTypes is needed as well (even if there is a RemoteContainerTypeDescription). The IContainerInstantiator.getSupportedConfigTypes() (and getSupportedIntents) allow the provider to determine at runtime the values for this container meta-data...as there's no other way for the rest of ECF to interact with a provider (IContainerInstantiator is it). Also...my assumption is that the default/typical implementation for IContainerInstantiator.getSupportedConfigTypes() will be return new String[] { description.getName() }; i.e. just the unique name of the name of the container type description for the given provider. The getSupportedConfigTypes can/would be customized by the provider...and allow it to expose *synonyms* config types (synonym config types are allowed in chap 13, and I think it would be helpful to support them with the ECF/provider interface...i.e. through overriding BaseContainerInstantiator.getSupportedConfigTypes(). Right now, the above code is how I've implemented BaseContainerInstantiator (org.eclipse.ecf.core.provider.BaseContainerInstantiator...a base class for providers to use if they wish (rather than IContainerInstantiator). We still have a number of providers that implement IContainerInstantiator directly, but these should probably be moved over to use BaseContainerInstantiator in any event. Let me know what you think. Again, I agree that some separation would be desirable, but I'm not sure what to do with IContainerInstantiator. (In reply to comment #7) > I agree this separation seems desirable...but the main problem is that > ContainerTypeDescription actually just turns around and calls > IContainerInstantiator to get the container meta-data (at runtime)...and > RemoteContainerTypeDescription (if introduced) would have to do similarly...and > so a new method IContainerInstantiator.getSupportedConfigTypes is needed as > well (even if there is a RemoteContainerTypeDescription). Wouldn't a new sub-inteface IRemoteContainerInstantiator help which extends IContainerInstantiator and defines getSupportedConfigTypes(), ... (In reply to comment #8) > (In reply to comment #7) > > I agree this separation seems desirable...but the main problem is that > > ContainerTypeDescription actually just turns around and calls > > IContainerInstantiator to get the container meta-data (at runtime)...and > > RemoteContainerTypeDescription (if introduced) would have to do similarly...and > > so a new method IContainerInstantiator.getSupportedConfigTypes is needed as > > well (even if there is a RemoteContainerTypeDescription). > > Wouldn't a new sub-inteface IRemoteContainerInstantiator help which extends > IContainerInstantiator and defines getSupportedConfigTypes(), ... Yes. I've created a new interface: org.eclipse.ecf.core.provider.IRemoteServiceContainerInstantiator public String[] getSupportedConfigTypes(ContainerTypeDescription description); public String[] getSupportedIntents(ContainerTypeDescription description); I've also updated ContainerTypeDescription to add this new method, and call it if the container instantiator is of right type (otherwise it just returns empty String[]s). Thanks. Progress update on this bug I've changed over the ECF distribution provider (i.e. org.eclipse.ecf.osgi.services.distribution) to use the service property names as specified in chapter 13 of the OSGi r4.2 compendium specification rather than RFC119. The remote service tests and hello examples now work...using the new property name...so the implementation is now minimally functional. There is still some work to do...e.g. to handle the proper new logic for the intents and config types, but what's there now is functioning. It seems some API, such as IContainerInstantiator's getSupportedIntents(ContainerTypeDescription), was removed. Was this intentional? (In reply to comment #11) > It seems some API, such as IContainerInstantiator's > getSupportedIntents(ContainerTypeDescription), was removed. Was this > intentional? Yes. With the introduction of IRemoteServicesContainerInstantiator getSupportedIntents logically belongs there. (In reply to comment #12) > (In reply to comment #11) > > It seems some API, such as IContainerInstantiator's > > getSupportedIntents(ContainerTypeDescription), was removed. Was this > > intentional? > > Yes. With the introduction of IRemoteServicesContainerInstantiator > getSupportedIntents logically belongs there. Is the bundle version going to change? API has been broken in this scenario. (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > It seems some API, such as IContainerInstantiator's > > > getSupportedIntents(ContainerTypeDescription), was removed. Was this > > > intentional? > > > > Yes. With the introduction of IRemoteServicesContainerInstantiator > > getSupportedIntents logically belongs there. > > Is the bundle version going to change? API has been broken in this scenario. Yes, it will change. The complicating factor for the bundle number change is the fact that the ECF core bundles are contributed to the platform (for p2)...and so a version number change of the core has to be coordinated with the platform build in terms of timing. But, it will change (probably 3.1.0). Committed additions for this bug to HEAD. These additions included additions to ecf core to support access to provider-specified meta-data about remote services providers: service exporter meta-data: service intents config types service importer meta-data: imported configs: the importer's config type(s) corresponding to the exporter's config type(s) (e.g. ecf.generic.client for ecf.generic.server or ecf.r-osgi.peer for ecf.r-osgi.peer). This allows providers to specify the types of containers that are compatible between service exporters and importers. imported config properties: Any provider-specific config properties Added lots of changing/refactoring of org.eclipse.ecf.osgi.services.distribution and discovery to support OSGi 4.2-specified handling of service properties/meta-data. Continuing work toward completion. I've added the following: 1) Support for the r-osgi provider (to expose the new configs and intents meta-data) 2) Test code to test the r-osgi provider (in org.eclipse.ecf.tests.osgi.services.distribution). 3) Small fixes in r-osgi provider discovered via running tests in 2. The ECF impl of OSGi 4.2 remote services is complete and tested with the ECF generic and r-osgi providers. There is the following left to do: a) Add to the tracing, so that if desired consumers can easily examine what is happening in the implementation b) Add testing code to test more completely other parts of the implementation (e.g. handling of intents) c) Test the JMS provider, and assure that the ECF impl can handle the requirements of registering a remote service via a client in a pub/sub group (i.e. not a 'server'). Initial implementation and test code completed, so marking plan bug as resolved. |