Java Reference
In-Depth Information
An ACTIVE bundle can be stopped, which also results in a transition back to the
RESOLVED state via the STOPPING state. The STOPPING state is an implicit state like START-
ING , and the bundle is in this state while its activator's stop() method executes. A
stopped bundle transitions back to RESOLVED instead of INSTALLED because its depen-
dencies are still satisfied and don't need to be resolved again. It's possible to force the
framework to resolve a bundle again by refreshing it or updating it, which we'll discuss
later. Refreshing or updating a bundle transitions it back to the INSTALLED state.
A bundle in the INSTALLED state can be uninstalled, which transitions it to the
UNINSTALLED state. If you uninstall an active bundle, the framework automatically
stops the bundle first, which results in the appropriate state transitions to the
RESOLVED state and then transitions it to the INSTALLED state before uninstalling it. 1 A
bundle in the UNINSTALLED state remains there as long as it's still needed (we'll
explain later what this means), but it can no longer transition to another state. Now
that you understand the complete bundle lifecycle, let's discuss how these operations
impact the framework's bundle cache and subsequent restarts of the framework.
3.2.6
Bundle cache and framework restarts
To u s e b u n d l e s , y o u h a v e t o i n s t a l l t h e m i n t o t h e OSG i framework. Check. But what does
this mean? Technically, you know you must invoke BundleContext.installBundle()
to install a bundle. In doing so, you must specify a location typically interpreted as a URL
to the bundle JAR file or an input stream from which the bundle JAR file is read. In
either case, the framework reads the bundle JAR file and saves a copy in a private area
known as the bundle cache . This means two things:
Installing a bundle into the framework is a persistent operation.
After the bundle is installed, the framework no longer needs the original copy
of the bundle JAR file.
The exact details of the bundle cache are dependent on the framework implementa-
tion; the specification doesn't dictate the format nor structure other than that it must
be persistent across framework executions. If you start an OSG i framework, install a
bundle, shut down the framework, and then restart it, the bundle you installed will
still be there, as shown in figure 3.6. If you compare this approach to using the class
path, where you manually manage everything, having the framework cache and man-
age the artifacts relieves you of a lot of effort.
In terms of your application, you can think of the bundle cache as the deployed
configuration of the application. This is similar to the chapter 2 discussion of creating
different configurations of the paint program. Your application's configuration is
whichever bundles you install into the framework. You maintain and manage the con-
figuration using the API s and techniques discussed in this chapter.
1
This is a change in the R4.2 version of the OSGi specification. You can't go to UNINSTALLED from RESOLVED ;
you have to go to INSTALLED first, and only INSTALLED goes to UNINSTALLED . This detail is listed in the R4.2
specification errata.
Search WWH ::




Custom Search