Managing bundles - OSGi in Action - page 315

9.3.1 Understanding activation policies

Although the OSG i specification defines activation policies in an open-ended way,
there's currently only one activation policy: lazy . The main gist of the lazy activation
policy is this:

A bundle declares itself to be lazy.

1

A management agent installs a lazy bundle and starts it lazily. The framework
marks the bundle as started but doesn't yet activate it.

2

The lazy bundle's activation is deferred until a class is loaded from it.

3

After a class is loaded from the lazy bundle, the framework completes its activa-
tion as normal.

4

This is fairly straightforward, but some small details lurk inside. Let's revisit the bun-
dle lifecycle diagram in figure 9.8 to get a better understanding of the impact.
The bold arrows in figure 9.8 depict additional transitions in the bundle lifecycle
state diagram. When a bundle is started lazily, it transitions to the STARTING state,
which is denoted by the framework by firing a BundleEvent of type LAZY_ACTIVATION ,
instead of the normal STARTING event. The bundle stays in this state until it's stopped
or a class is loaded from it. Stopping a lazy bundle in the STARTING state returns it to
the RESOLVED state and results in STOPPING and STOPPED bundle events. When a class is
loaded from a lazy bundle in the STARTING state, this acts as a trigger for the frame-
work to automatically activate the bundle, which completes the normal process of cre-
ating the bundle activator and calling its start() method, resulting in the normal
STARTING and STARTED bundle events.

Install

Lazily started

Update
Refresh

Installed Starting

Start

Refresh
Update

Trigger

Resolve

Stop

Resolved Active

Uninstall

Stop

Uninstalled

Stopping

Figure 9.8 The lazy activation policy causes a bundle to defer activation and linger
in the STARTING state until a class is loaded from it, at which point the framework
completes its activation.