[
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:
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?
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.
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.
Thanks,
Scott