Re: [equinox-dev] OSGi new startup policies

[Thomas Watson <tjwatson@xxxxxxxxxx>]

I opened the following bugs:

Platform->Update https://bugs.eclipse.org/bugs/show_bug.cgi?id=174334
Equinox->Framework https://bugs.eclipse.org/bugs/show_bug.cgi?id=174335

See comments below:

equinox-dev-bounces@xxxxxxxxxxx wrote on 02/15/2007
08:45:20 AM:

> Has somebody submitted bug already for tracking this? I couldn't find
it.
> 
> Is there an idea forming in someone mind what should be the behavior
of
> the update.configurator and osgi.bundle?
> 
> One simple solution is to start all bundles with
> start(START_ACTIVATION_POLICY). This will properly bring the lazy
> bundles in proper state, but will unnecessary start "library"
bundles
> (bundles without Bundle-Activator). Solution to this might be a check
> for the presence of Bundle-Activator. However, if activating bundle
> which doesn't have Bundle-Activator doesn't create its classloader,
this
> will not be even a problem.

I'm not sure we want to change the behavior of update
to eagerly start 
bundles which do not define the "lazy" activation
policy.  I agree that 
it may not be a performance issue if the bundles do
not have an activator 
but this is still a pretty drastic change in behavior
from before where 
no bundles were started.  I do agree that update.configurator
should at 
least call start(START_ACTIVATION_POLICY) on bundles
that declare a lazy 
activation policy.  These are for bundles that
define the following headers

Eclipse-LazyStart: true
Eclipse-LazyStart: false; exceptions=<some package
list>
Bundle-ActivationPolicy: lazy

There is also the deprecated Eclipse-AutoStart that
is the same as
Eclipse-LazyStart

Today this is still working because Equinox has a
compatibility setting 
that is enabled by default to automatically start
all bundles with 
the START_ACTIVATION_POLICY if they define a lazy
activation policy.
That is why lazy activated bundles are able to start
even though 
Bundle.start(START_ACTIVATION_POLICY) was not called.

> 
> Bundles from osgi.bundles property, marked with 'start' attribute,
can
> be started with start(0). One use case for this is the following:
the
> registry can be lazy activated. However, it may be good to pay the
price
> of the startup time of the registry and load the registry cache and
then
> use the BundleEvents to handle the new bundles (installed by
> update.configurator, for example) instead of lazy activating the
> registry later just to find that you need to parse all bundles. In
other
> scenario you may need every single ms of the startup and decide that
the
> registry needs to be lazy loaded. No problem. Don't specify 'start'
> attribute.
> 

We should probably use the same policy as update.configurator
here.
If 'start' attribute is used the do the normal start(0)
otherwise call start(START_ACTIVATION_POLICY) if it
is appropriate
(i.e. the bundle has a lazy activation policy).

> The good thing about update.configurator using
> start(START_ACTIVATION_POLICY) is that you can deploy plugins which
will
> be activated automatically. The only thing you need to do is make
sure
> that the bundle has no Bundle-ActivationPolicy header. This way, the
> bundle will be activated.
> 
> Any comments?
> 
>