> As to the question of DS, let's not forget that it is just an > instrument. From what I understand, its goal is to help developers > work around OSGi complexities. If it does not help, it needs to be fixed.
I am all for fixing DS if it is flawed. But your argument against using startlevel can be applied to anything which attempts to fix some ordering. The difficult point is that bundles can be interdependent. They and services are dynamic. You can attempt to hide the dynamism through the use of static policies in DS but that only goes so far. Using DS, one can fairly easily deal with service dynamism. There are bind/unbind methods which are called when services come and go so the bundle can be notified of changes to the set of services. I feel that changing DS to perform service registration synchronous with bundle activation will likely result in deadlocks when there are complex service dependency graphs. One possible way to deal with this is through the use of component enablement. Using the original example of service A depending upon some number of service B, if you can know when all the service Bs are available, one can write a component with a dynamic dependency on B. When all the Bs are available then enable the component providing service A (which are declared disabled in its description). The trick is of course to be able to know when all the service Bs are available such that we are ready to enable serviceA. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
