Java Reference
In-Depth Information
case Bundle.INSTALLED:
return "INSTALLED";
case Bundle.RESOLVED:
return "RESOLVED";
case Bundle.STARTING:
return "STARTING";
case Bundle.ACTIVE:
return "ACTIVE";
case Bundle.STOPPING:
return "STOPPING";
default:
return "UNKNOWN";
}
}
private void printBundle(long id, String state, String name,
String location, String symbolicName) {...}
}
The implementation of this command is pretty easy too, because you only need to use
BundleContext.getBundles()
to get an array of all bundles currently installed in the
framework. The rest of the implementation loops through the returned array and
prints out information from each
Bundle
object. Here you print the bundle identifier,
lifecycle state, name, location, and symbolic name for each bundle.
With this command in place, you have everything you need for the simple shell.
You can install, start, stop, update, and uninstall bundles and list the currently
installed bundles. That was fairly simple, wasn't it? Think about the flexibility at your
fingertips versus the amount of effort needed to create the shell. Now you can create
applications as easily deployable configurations of bundles that you can manage and
evolve as necessary over time.
Before you move back to the paint program, two final lifecycle concepts are worth
exploring in order to fully appreciate the approach you'll take to make the paint pro-
gram dynamically extensible: persistence and events. We'll describe them in the con-
text of the shell example; but as you'll see in the paint example in a couple of pages,
they're generally useful tools to have in mind when building
OSG
i applications.
3.3.4
Persisting bundle state
As we mentioned when discussing bundle activators, the framework creates an
instance of a bundle's activator class and uses the same instance for starting and subse-
quently stopping the bundle. An activator instance is used only once by the framework
to start and stop a bundle, after which it's discarded. If the bundle is subsequently
restarted, a new activator instance is created. Given this situation, how does a bundle
persist state across stops and restarts? Stepping back even further, we mentioned how
the framework saves installed bundles into a cache so they can be reloaded the next
time the framework starts. How does a bundle persist state across framework sessions?
There are several possibilities.
