[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: Autostarting required plugins

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.


> 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.