[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] OSGi new startup policies

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

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?