Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Debugging RFC 119 
Scott,


On May 19, 2009, at 3:40 PM, Scott Lewis wrote:


Hi Bryan,

Bryan Hunt wrote:

Scott,
First off, I was able to get DS to start after the bundle that creates the container. My problem was that I was creating the container in the Application instead of the Activator, and it seems that the Application gets called after all bundles have been activated. I moved the creation of the container to the Activator, and now I see my service being used by R-OSGi, and ecf.osgi.services.distribution. Goodness :) 

Great.


<stuff deleted>
It could be that I'm just not communicating effectively here. Here's my current thinking (with rather limited knowledge of ECF) on how it should work. If you see a service registered with osgi.remote.interfaces = * and there are no containers, ignore the service (with the bug fix for the NPE, I think this happens now). When an appropriate container is constructed, hook the listener for any new services, and look for any already existing registered services with osgi.remote.interfaces = * and export them as remote services.
It appears that ECF currently does not look for services registered prior to the construction of the container.
Ok, I see. Just so I understand...the expectation would be that when a remote service container is created that it would look for remote services registered prior to the construction of the container, and when/if found would subsequently distribute them. Is that right? 

Yep, that's right.
If I've misunderstood this point, then maybe there's another bug lurking here.
We don't have this functionality now, admittedly. I have to think some about the implications of such an approach...i.e. how would it work...but perhaps you would open a bug to this effect and we can track it and discuss there? This isn't something that we can/could have instantaneously, but the basic mechanisms are there to support it (e.g. IContainerManagerListener), so I believe it could be supported without major API changes.
I have one other thing to say about this (I understand now that what you are asking for is not this, but I thought I would point it because it does handle related use cases)...is that we also have two service interfaces: IHostContainerFinder and IProxyContainerFinder (which are implemented by DefaultHostContainerFinder and DefaultProxyContainerFinder respectively). It's also possible for applications to register themselves as IHost/ProxyContainerFinders, and implement 'lazy' container creation (as opposed to the eager container creation you are doing now). That is, a custom IHostContainerFinder could be defined like this
IRemoteServiceContainer[] findHostContainers(ServiceReference serviceReference, String[] remoteInterfaces,String[] remoteConfigurationType, String[] remoteRequiresIntents) { 
         // Here is the custom code
         if (rsContainer == null) {
                IContainer container = createContainer();
rsContainer = new RemoteServiceContainer(container, (IRemoteServiceContainerAdapter) container.getAdapter(IRemoteServiceContainerAdapter.class)); 
         }
         return new IRemoteServiceContainer[] { rsContainer };
  }
This way only if remote services are actually registered will a container be created/used...i.e. if no remote services are registered this code will never be called. 



This approach might actually work for me.  I'll look into this more.
I understand now that this is not what you are looking for, but I also am working on some documenting about different ways to use/ customize the ECF RFC119 implementation and this addresses some use cases as well. 




<stuff deleted>
Does this make sense?
Yep, that makes sense. The problem I see here is that my remote services should not have to depend on the container manager. DS can register my services in any order, so for this technique to work, each service would have to implement this code in addition to checking whether or not the container already existed. 

OK, sounds good.  Lets discuss further and details on the new bug.


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



Thanks,

Scott


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top