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

[Mel Martinez <melm@xxxxxxxxxx>]

Well, I'm open to any and all improved proposals.

You say 'Start levels are ... NOT intended to be used to handle detailed
initialization order ...'  (emphasis mine)

Isn't that exactly what is being asked for in this thread?  Deterministic
start order?    And for that purpose, start levels themselves are brittle.

I'm not advocating here for a particular solution.  I'm advocating that
some thought be put into coming up with a decent solution that is based on
symbolic relationships rather than rely on the fragile relationship of some
arbitrary weight attribute.

Passive, non-deterministic order resolution based on lazy initialization is
fine for many types of deployments, but not all.  In a server, one tends to
want some or all initialization be expensed at once in a deterministic
fashion prior to exposure of services to clients.

If we think the problem is too hard to solve because of reasons X, Y & Z,
then that's okay.   'Doesn't make the desire to solve it any less
important.

-mel

Peter Kriens <Peter.Kriens@xxxxxxxx> wrote on 02/14/2006 12:19:19 PM:

> Ouch!
>
> Trying to order initialization is an unsolved problem in open ended
> systems ... Not only creates it a false idea of security, it falls
> apart when parts are updated, become unavailable, like in real life.
>
> Application bundles must be resilient to things coming and going, or
> you will never get it work in an open ended system like OSGi. Start
> levels are intended to have a flash screen, get some basic work done
> before everybody wants the processor, handle JARs you can't modify, etc.
> They are NOT intended to be used to handle detailed initializion order
because
> this will burn you.
>
> We have excellent dependency management and associated events. Your
> proposal creates extremely brittle solutions.
>
> Kind regards,
>
>      Peter Kriens
>
> MM> Hi Jeff,
>
> MM> I want to put my plug in for a 'better' start dependency model.
>
> MM> The trend I've seen in some of the implementations is to use
variations on
> MM> a 'run-level' type of mechanism to control the start order.
Ultimately,
> MM> that boils down to: each bundle is given a number and that determines
the
> MM> start order.
>
> MM> The problem with this sort of model is that it assumes that you know
the
> MM> start level number of your dependencies so you make sure you put your
> MM> number so that it follows theirs.  That is, of course, fragile
> if, for some
> MM> reason your dependencies need to later adjust their own start levels
> MM> because of some dependency that they have!
>
> MM> It would be much better to use a method where we recognize that
> start order
> MM> dependencies need to be declared symbolically just like runtime
> MM> dependencies.  In the manifest, and using bundle symbolic names.
>
> MM> In other words, I propose that if we do anything at all in the space
of
> MM> standardizing start order,  that we create a manifest header
fordeclaring
> MM> the start-order dependencies.   The header simply lists those bundles
that
> MM> this bundle KNOWS it must follow in the start order.
>
> MM> Bundle-StartFollows : <bundle id> [, <bundle id> [, ...]]
>
> MM> At launch time,  a 'Start Order Resolver' simply scans these values
and
> MM> resolves the start order.   This order can be cached and reused
> if there is
> MM> no change to the configuration.   This order of course, is not
applicable
> MM> to lazy (classload-initiated) starting.
>
> MM> Thoughts?
>
> MM> -mel
>
> MM> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote on 02/14/2006 01:50:07
AM:
> >>
> >> Your summary of the situation is quite accurate.  One thing that I
will
> >> point out however is that this is really an OSGi thing not an
> >> Eclipse/Equinox thing.  OSGi explicitly stays out of defining how/when
> >> bundles are started.  This is great from a spec point of view as it is
> >> much more flexible.  Its a bit of a bummer from a consumer point of
view
> >> since each framework implmentation does things differently.  Some
> >> frameworks, for example, have been known to aggressively start all
> MM> bundles
> >> when they are installed.  Other folks have implemented something like
you
>
> >> suggest and have someone that starts bundles for them according to
> >> whatever policy they want.
> >>
> >> We have talked about a couple ideas that might help with using update
> >> manager and getting bundles started at install time but are focused on
M5
>
> >> right now and have not implemented anything.
> >>
>
> MM> _______________________________________________
> MM> equinox-dev mailing list
> MM> equinox-dev@xxxxxxxxxxx
> MM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> --
> Peter Kriens                              Tel +33870447986
> 9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
> 34160 Beaulieu, France                    ICQ 255570717
> Skype pkriens                             Fax +1 8153772599
>