> > I feel that changing DS to perform service
registration synchronous with
> > bundle activation will likely result in deadlocks when there
> > service dependency graphs.
> This won't be any different from what is done now manually. The
> potential for deadlocks are there regardless of DS.
Perhaps, but at least we are not building it into
the DS spec or the DS impl!
> > One possible way to deal with this is through the use of component
> > enablement. Using the original example of service A depending
> > number of service B, if you can know when all the service Bs
> > available, one can write a component with a dynamic dependency
> > When all the Bs are available then enable the component providing
> > service A (which are declared disabled in its description). The
> > of course to be able to know when all the service Bs are available
> > that we are ready to enable serviceA.
> And we are back to the core problem: we cannot be sure when all service
> Bs are available.
How can you ever be sure? :-) Unless there is some
definition of the expected set of Bs, it is just random.
> In code which doesn't use DS, start() method
> serve as a boundary for the service changes - satisfied services will
> registered while the bundle is starting and any services which becomes
> satisfied will be registered synchronously (the latter is the current
> behavior of DS).
This makes the assumption that bundle will always
register their B during BundleActivator execution. I think this is a fairly
tall assumption. What if a bundle's B depends upon something which is not
yet available? It is very bad form to block the BundleActivator. So such
a bundle, if well behaved, would have to return from the BundleActivator
w/o having registered B and delay registering B until the dependency is
met some time later.
> After all the bundles are activated, we
can be sure
> that all services which doesn't depend on external factors will be
> available and the system can be considered ready.
You assume ("all services which doesn't depend
on external factors") that all B's have no dependencies and can be
registered at will. That is a pretty big assumption.
Perhaps one thing a DS impl could do, is to register
all services for which all dependencies are currently met synchronously
during bundle activation. All other services would have to handled asynchronously.
This splits the DS work between work that can be quickly done during bundle
activation and work that will take time which is done after bundle activation.
I don't think any change to the DS spec is needed to allow this behavior.