[
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