Learning lifecycle - OSGi in Action - page 75

This shows you in practice that you can use the lifecycle API to build a highly dynamic
application, but what's going on in this example? To understand, we'll take a top-
down approach, using the shell and paint example for context:

In section 3.2.2, we'll explain the framework's role in the application's lifecycle.

■

In section 3.2.3, we'll look at the changes you need to make to the bundle man-
ifest to hook the bundles into the OSG i framework.

■

In section 3.2.4, we'll investigate the key API interfaces used by the OSG i lifecy-
cle: BundleActivator , BundleContext , and Bundle .

■

In section 3.2.5, we'll wrap up with a review of the OSG i lifecycle state diagram.

■

Let's get started.

3.2.2 The OSGi framework's role in the lifecycle

In standard Java programming, you use JAR files by placing them on the class path.
This isn't the approach for using bundles. A bundle can only be used when it's
installed into a running instance of the OSG i framework. Conceptually, you can think
of installing a bundle into the framework as being similar to putting a JAR file on the
class path in standard Java programming.
This simplified view hides some important differences from the standard class
path, as you can see in figure 3.3. One big difference is the fact that the OSG i frame-
work supports full lifecycle management of bundle JAR files, including install, resolve,
start, stop, update, and uninstall. At this point, we've only touched on installing bun-
dles and resolving their dependencies. The remainder of this chapter will fully
explain the lifecycle activities and how they're related to each other. For example,
we've already mentioned that the framework doesn't allow an installed bundle to be
used until its dependencies ( Import-Package declarations) are satisfied.

JAR JAR JAR

Class path

ll

ll ll

Bundle

Bundle

Bundle

OSGi framework

Figure 3.3 Class path versus OSGi framework with full lifecycle management