equinox-dev-bounces@xxxxxxxxxxx wrote on 02/15/2007
> Has somebody submitted bug already for tracking this? I couldn't find
> Is there an idea forming in someone mind what should be the behavior
> 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 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,
> 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
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,
> be started with start(0). One use case for this is the following:
> registry can be lazy activated. However, it may be good to pay the
> of the startup time of the registry and load the registry cache and
> 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
> scenario you may need every single ms of the startup and decide that
> registry needs to be lazy loaded. No problem. Don't specify 'start'
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
> be activated automatically. The only thing you need to do is make
> that the bundle has no Bundle-ActivationPolicy header. This way, the
> bundle will be activated.
> Any comments?