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

[Olivier Gruber <ogruber@xxxxxxxxxx>]

Let's try to avoid extreme positions...


At a core level, things are asynchronous
in nature. So things come and go and people use those things need to be

prepared for that. But this is at the
level of core mechanisms, not policies. At some level of the system, things
are
more ordered, it is also the nature
of things.

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.

Declarative services is one of those.
It provides order for activation and deactivation above fully asynchronous

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. 

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. 

With declarative services, is this enough?
It seems enough for services, but we do not only have services. 
Is a similar support necessary for modules?
Modules have an activator, it runs code. Modules have static initializers
on
classes, they run code. There is effectively
no ability to order things there beyond start levels, and as Mel points
out,
start levels is a rather simple model
(simpler that what we have for services, that's for sure).

Furthermore, correct me if I am wrong,
I don't recall that we can control the various activation of the different

components of a bundle. They are activated
independently, as their dependencies are being resolved. So effectively,

a bundle may become partially activated
(a few components are activated and others are not). However, a bundle
may not be able to provide only a subset
of its functionality. 

So I thing what Mel is asking is a fair
question. I would state the following points:

(1) We need to clarify what are mechanisms
and what are policies, especially that we are slowly adding more of those.
It is more important than ever that
we retain generic flexible mechanisms at our core, but we are also facing
the fact
that we may want to promote one or more
higher-level programming models including some policies. 

(2)  We need to consider if DS
are sufficient? Do we need to have some control on what components of a
bundle may 
be activated and when? 

(3) What about modules and their activators?


Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center

Mel Martinez/Cambridge/IBM@IBMUS Sent by: equinox-dev-bounces@xxxxxxxxxxx 02/14/2006 06:59 PM Please respond to Equinox development mailing list

To:        equinox-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [equinox-dev] Re: Autostarting required plugins

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
>

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