Managing bundles - OSGi in Action - page 316

Because loading a class from one lazy bundle may require other classes to be loaded
from other lazy bundles, the framework may end up activating chains of lazy bundles.
The framework doesn't activate the lazy bundles as it loads classes from them, because
this can lead to arcane class-loading errors. Instead, the framework delays the activa-
tion of each lazy bundle it discovers in a class-loading chain until it finishes loading
the instigating class. At that point, the framework activates the detected lazy bundles
in reverse order. For example, assume ClassA is loaded from bundle A, which
requires ClassB from bundle B, which in turn requires ClassC from bundle C. If all of
the bundles are lazy and in the STARTING state, the framework will activate bundle C,
bundle B, and then bundle A before returning ClassA to the requester.

Attention!
Be aware that loading resources from a bundle doesn't trigger lazy activation, only
classes. Also, the specification doesn't unambiguously define how the framework
should treat the class-loading trigger, so the precise behavior may vary. In particular,
some frameworks may scope the trigger to the lifetime of the bundle's class loader
(it needs to be re-triggered only if the bundle is refreshed), whereas others may scope
the trigger to the bundle's ACTIVE lifecycle state (it needs to be re-triggered after the
bundle is stopped and restarted).

Now that you know how the lazy activation policy works, let's look into the details of
using it.

9.3.2 Using activation policies

The process of using activation policies involves both the bundle wishing to be lazily
activated and the management agent deciding whether to start a bundle lazily. For the
first, when you create a bundle that can be lazily activated, you use the Bundle-
ActivationPolicy header in its manifest metadata to declare the activation policy.

BUNDLE-ACTIVATIONPOLICY Specifies the activation policy of a bundle where
the only defined policy is lazy activation, which is specified with the value
lazy . The default behavior is eager activation, although there is no explicit
way to specify this value.

To u s e t h i s i n t h e b u n d l e m a n i f e s t , y o u d o t h i s :

Bundle-ActivationPolicy: lazy
Only bundles containing this manifest header can have their activation deferred. It's
not possible to lazily activate an arbitrary bundle. The reasoning behind this goes back
to one of the main use cases motivating deferred activation: a bundle that requires a
BundleContext for its exported packages to function properly. In this use case, only
the bundle itself knows if this is the case; thus, only the bundle itself can declare
the policy.