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,
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 :) 

See also below....


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


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.
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. If I've misunderstood this point, then maybe there's another bug lurking here.
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?
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. 


Scott

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

Back to the top