Re: [equinox-dev] Re: Autostarting required plugins

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

equinox-dev-bounces@xxxxxxxxxxx wrote on 02/15/2006
06:56:50 AM:

> Let's try to avoid extreme positions... 

Where's the fun in that?! ;-)

> Before declarative services and before start
levels, OSGi position 
> was clear: it is not a core mechanism issue, 
> it is a policy issue, it goes in the "management agent"
black box. I
> continue to believe that we need to retain 
> core mechanisms that are flexible, but the needs for higher-level
> frameworks are pressing too. 

Yup

> mechanisms. The Eclipse registry does the same,
it provides order 
> for plugins based on two rules: (1) a 
> bundle is activated before it used (any class load) and (2) the 
> bundle activation obeys the bundle-require 
> dependencies (a required bundle being started first). In other 
> words, bundle-require dependencies tell what you 
> need, where to get it from, and also tells the activation order. 

Clarification.  Eclipse-LazyStart (nee Eclipse-AutoStart)
activates bundles *only* based on classloading.  Activating A does
not activate B unless the activation of A requires classes that are actually
supplied by B.  Note also that it is not the mere asking for a class
from B that will trigger the activation.  There has to be a reasonable
expectation that B will actually have the requested class.  This approach
works well in certain scenarios but, as the name implies, it is a rather
passive approach.

> So Mel has a point, start order is a delicate
issue, that has not 
> been fully addressed by OSGi. 
> I am not saying this was a mistake, I am just saying that with start
> levels and then declarative services, 
> OSGi has entered the realm of higher-level programming models, where
> ordering matters in some cases. 

I agree with a caveat.  BJ's and Peter's points
in other posts are on target here.  In general bundles, componetns,
modules, ... should be more resilient wrt things coming and going.  Two
issues however.  1) this is often hard to actually program.  Its
not an excuse but telling everyone that they have to program this way raises
the bar.  2) There are times when ordering is absolutely required.
 Managing this in a standard way would be interesting to explore.
 This was raised at the OSGi World Congress as one of the things that
people wanted.

> With declarative services, is this enough? It
seems enough for 
> services, but we do not only have services. 

Actually, there are other issues.  One case...
If I have a bundle that supplies a service S and requires some other service
T (both declaratively), it appears that that component is not started until
the requirement for service T is actually triggered in code.   So
if S is, for example, the HTTP service, the port is not opened and active
until, for some reason, someone goes for service T.  So the problem
of how to start your system is still there.

Jeff