Community
Participate
Working Groups
It seems that the org.eclipse.ecf.containerFactory extension point doesn't support the old style ContainerInstantiator using a IDiscoveryContainerAdapter anymore. Orginaly it was used like: -------------------- <containerFactory class="x.y.z.MyServiceContainerInstantiator" description="MyService Discovery Container" name="ecf.discovery.myservice"> </containerFactory> --------------------- Instead it is possible to use the new style with seperated Locator and Advertiser which uses IDiscoveryLocator and IDiscoveryAdvertiser: -------------------------- <containerFactory class="x.y.z.MyServiceContainerInstantiator" description="MyService Discovery Container" name="ecf.discovery.myservice.locator"> </containerFactory> <containerFactory class="x.y.z.MyServiceContainerInstantiator" description="MyService Discovery Container" name="ecf.discovery.myservice.advertiser"> </containerFactory> ------------------ There are two points: 1. As long as the IDiscoveryContainerAdapter exists even if it is deprected the corresponding extension should work. 2. The use of two extension point entry's now causes that there are also two instances of MyServiceContainerInstantiator even when there is one single class implementing both.
(In reply to comment #0) > There are two points: > 1. As long as the IDiscoveryContainerAdapter exists even if it is deprected the > corresponding extension should work. The bundle major version has been correctly incremented indicating non-compatible changes. Unfortunately this cannot be expressed on the extension directly, as extensions don't support versioning. :-( > 2. The use of two extension point entry's now causes that there are also two > instances of MyServiceContainerInstantiator even when there is one single class > implementing both. True, do you see this is a performance issue? All in all good examples why we should have modeled this as OSGi services instead of extensions.
The downsite of the two instances is that before it was possible to have a singelton which handles both. For the SLP Discovery it seems that there are now two Threads/Jobs running and doing discovery. Is that wanted ? The same applies to our implementations for our cutom lcoal Discovery. I agree it is nice to have two extension points to allow an implementor to seperate Advertiser and Locator, but why not keep the other extension point for an implementor who wants/needs to have only one instance which implements both ? cheers Christian
(In reply to comment #2) > The downsite of the two instances is that before it was possible to have a > singelton which handles both. > > For the SLP Discovery it seems that there are now two Threads/Jobs running and > doing discovery. Is that wanted ? I assume this happens when the jSLP discovery provider gets used along with the Composite provider. Without Composite, the discovery thread in jSLP is only activated upon add*Listener calls which never happens for the advertiser. > The same applies to our implementations for our custom local Discovery. Same problem. Composite makes no difference if is deals with an advertiser or locator. It just wraps it. If jSLP discovery container would be refactored into an advertiser and locator, the problem would go away. > I agree it is nice to have two extension points to allow an implementor to > seperate Advertiser and Locator, > but why not keep the other extension point for an implementor who wants/needs > to have only one instance which implements both? Might be possible, do you have spare resource to provide a patch?
Resolving as worksforme. If there is more to do here (i.e. comment 3) please reopen.
