Learning lifecycle - OSGi in Action - page 83

With this knowledge in hand, we'll complete the top-down approach by defining the
overall bundle lifecycle state diagram and see how these interfaces relate to it.

3.2.5 Lifecycle state diagram

Until now, we've been holding off on explicitly describing the complete bundle
lifecycle in favor of getting a high-level view of the API forming the lifecycle layer.
This allowed you to quickly get your hands a little dirty. Now you can better under-
stand how these API s relate to the complete bundle lifecycle state diagram, shown in
figure 3.5.
The entry point of the bundle lifecycle is the BundleContext.installBundle()
operation, which creates a bundle in the INSTALLED state. From figure 3.5, you can
see that there's no direct path from INSTALLED to STARTING . This is because the
framework ensures all dependencies of a bundle are satisfied before it can be used
(that is, no classes can be loaded from it). The transition from the INSTALLED to the
RESOLVED state represents this guarantee. The framework won't allow a bundle to
transition to RESOLVED unless all its dependencies are satisfied. If it can't transition
to RESOLVED , by definition it can't transition to STARTING . Often, the transition to
RESOLVED happens implicitly when the bundle is started or another bundle tries to
load a class from it, but you'll see later in this chapter that it's also possible to explic-
itly resolve a bundle.
The transition from the STARTING to the ACTIVE state is always implicit. A bundle is
in the STARTING state while its activator's start() method executes. Upon successful
completion of the start() method, the bundle's state transitions to ACTIVE ; but if the
activator throws an exception, it transitions back to RESOLVED .

Install

Update
Refresh

Installed Starting

Refresh
Update

Resolve

Start

Resolved Active

Uninstall

Stop

Uninstalled

Stopping

Figure 3.5 OSGi bundle lifecycle