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

[BJ Hargrave <hargrave@xxxxxxxxxx>]

I think this is just a mess.

Why is this necessary? Bundles should not have these dependencies on 
ordering of start up. If bundle A needs a service from bundle B, A should 
not required B to be started first. Perhaps B is later replaced by a 
better implementation of the service using bundle C. Now A has a hard 
dependency on B. This is extremely tight coupling and brittle. A should be 
prepare to "wait" for the interesting service to become available. Either 
use ServiceListener, ServiceTracker or Declarative Services.

I understand that some ordering is necessary for bootstrapping some 
initial bundles or some startup performance, but in general the vast 
majority of bundles should not require such brittle ordering dependencies. 
A should be prepared for the service to be unregister if B is updated or B 
is replaced by C, so A is poorly written if it cannot start up without the 
service present.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Mel Martinez/Cambridge/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2006-02-14 10:50 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
equinox-dev@xxxxxxxxxxx
cc
Mel Martinez/Cambridge/IBM@IBMUS
Subject
[equinox-dev] Re: Autostarting required plugins






Hi Jeff,

I want to put my plug in for a 'better' start dependency model.

The trend I've seen in some of the implementations is to use variations on
a 'run-level' type of mechanism to control the start order.  Ultimately,
that boils down to: each bundle is given a number and that determines the
start order.

The problem with this sort of model is that it assumes that you know the
start level number of your dependencies so you make sure you put your
number so that it follows theirs.  That is, of course, fragile if, for 
some
reason your dependencies need to later adjust their own start levels
because of some dependency that they have!

It would be much better to use a method where we recognize that start 
order
dependencies need to be declared symbolically just like runtime
dependencies.  In the manifest, and using bundle symbolic names.

In other words, I propose that if we do anything at all in the space of
standardizing start order,  that we create a manifest header for declaring
the start-order dependencies.   The header simply lists those bundles that
this bundle KNOWS it must follow in the start order.

Bundle-StartFollows : <bundle id> [, <bundle id> [, ...]]

At launch time,  a 'Start Order Resolver' simply scans these values and
resolves the start order.   This order can be cached and reused if there 
is
no change to the configuration.   This order of course, is not applicable
to lazy (classload-initiated) starting.

Thoughts?

-mel

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

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev