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

Bryan Hunt wrote:


<stuff deleted>
This is a small bug in the DefaultHostContainerFinder class (i.e. improper handling of null returned from the function causing the NPE). Yes a new bug would be helpful on this. 

Opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=276982 for this.


Thanks.  I've fixed the bug and released to HEAD.




<stuff deleted>
I don't consider the bundle start order issue an ECF bug...as we can't control or dictate the start order.
I agree that ECF can't control or dictate the start order, and this is why I think there's a bug here. ECF is currently dependent on a bundle constructing the container, and since start order should not be dictated (being a good OSGi citizen) ECF fails and is thus implicitly dependent on start order. Since the container is constructed by a bundle, it seems that ECF should treat the container like a service - it can come and go at any time since the bundle can come and go at any time.
I'm confused. Except for the bug above causing the NPE in the DefaultHostContainerFinder containers can come and go at any time.
I would like to understand how you would expect things to happen...that is, given that *some* implementation of distribution (r-osgi or some other) has to be started before it can respond to remote service registrations (i.e. and publish and distribute them), and we/ECF can't control the start of any of our bundles (including ECF, the EventHook, discovery, and the r-osgi provider), how would/could/can we prevent/make up for this situation? Even if we had a piece of code that created IContainer instances upon app startup, that code would also have to be explicitly started and so we would be back to the same situation.
I think the ultimate answer here is probably to use the OSGi ConfigurationAdmin, and use that to allow the ECF IContainerManager service to be configured and managed (i.e. by adding/creating IContainer instances on startup as determined by the/any persistent configuration data...e.g. a list of remote service providers to start like r_osgi or others). But I have to admit that we haven't yet been able to go into utilizing the ConfigurationAdmin service as yet.
Is it possible for you to call the Activator.getDefault().getContainerManager(1000).getContainerFactory().createContainer("ecf.r_osgi.peer"); before registering your remote service? There are a couple of ways to do this with DS I believe.
I'm not aware of any way to do that other than to try to get DS to start after the bundle that constructs the container. I've tried setting the start level of DS to 5 and the bundle that constructs the container is set to default (4), but DS is still starting way before the bundle that constructs the container. I'm going to spend a little time debugging the start order ... any other ideas for a workaround would be appreciated.
Rather than have your code run prior to DS, why not have DS call into your component prior to your remote service registration by specifying the IContainerManager as a service reference for your component, so that when the IContainerManager is registered as a service that it is then bound to your component (prior to your service being registered)...for example:
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"; immediate="true" name="org.equinoxosgi.toast.backend.discovery"> 
  <implementation class="com.your.service.component.FooImpl"/>
<reference bind="setContainerManager" cardinality="1..1" interface="org.eclipse.ecf.core.IContainerManager" name="containerManager" policy="static" /> 
  <service>
     <provide interface="com.your.service.component.Foo"/>
     <your remote service property here...I can't remember xml syntax>
  </service>
</scr:component>

Then in your FooImpl class you could have a bind method like this:

public void setContainerManager(IContainerManager containerManager) {
containerManager.getContainerFactory().createContainer("ecf.provider.r_osgi"); 
}
And DS would then call setContainerManager(IContainerManager containerManager) with the ECF containerManager service instance...all before your service component was activated and the Foo service registered. 

Does this make sense?

Scott

Back to the top