Re: [equinox-dev] OSGi new startup policies

[Danail Nachev <d_nachev@xxxxxxxxxx>]

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.

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.

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?

Jeff McAffer wrote:
> 
> This is a good thread.  It would seem that we will have some
> compatibility issues to work through.  Of course, if someone has
> Eclipse-LazyStart then we can still start them automagically.  For
> people looking to get on the new/standard header though we should make
> it possible/easy.
> 
> Perhaps there should be a bug opened to track this? (what release/build
> should we target for the changes?)  Here are some random thoughts about
> the scope of change
> - bundles installed by update.configurator
> - bundles installed by osgi.bundle
> - people looking at the state of bundles to decide what to do (e.g.,
> some people were previously looking and starting the bundle if it was in
> Resolved state).  Now they will not get quite what they expected/wanted...
> 
> Jeff
> 
>