Java Reference
In-Depth Information
Another huge difference from the standard class path is inherent dynamism. The
OSG i framework supports the full bundle lifecycle at execution time. This is similar to
modifying what's on the class path dynamically.
As part of lifecycle management, the framework maintains a persistent cache of
installed bundles. This means the next time you start the framework, any previously
installed bundles are automatically reloaded from the bundle cache, and the original
JAR files are no longer necessary. Perhaps we can characterize the framework as a fully
manageable, dynamic, and persistent class path. Sounds cool, huh? Let's move on to how
you have to modify the metadata to allow bundles to hook into the lifecycle layer API .
3.2.3
The bundle activator manifest entry
How do you tell the framework to kick-start the bundles at execution time? The
answer, as with the rest of the modularity information, is via the bundle metadata.
Here's the JAR file manifest describing the shell bundle you'll create:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.shell
Bundle-Version: 1.0
Bundle-Activator: org.foo.shell.Activator
Import-Package: org.osgi.framework;version="[1.3,2.0)",
org.osgi.service.packageadmin;version="[1.2,2.0)",
org.osgi.service.startlevel;version="[1.1,2.0)"
Bundle-Name: remote_shell
Bundle-DocURL: http://code.google.com/p/osgi-in-action/
You should already be familiar with most of these headers from chapter 2. But to
recap, most of the entries are related to the class-level modularity of the bundle. This
metadata does the following:
Defines the bundle's identity
Specifies the packages on which this bundle depends
Declares additional human-readable information
The only new header is Bundle-Activator . This is the first sighting of the OSG i lifecy-
cle API in action! The Bundle-Activator header specifies the name of a reachable
class (that is, either imported or on the bundle class path) implementing the org.
osgi.framework.BundleActivator interface. This interface provides the bundle with
a hook into the lifecycle layer and the ability to customize what happens when it's
started or stopped.
Is an activator necessary?
Keep in mind that not all bundles need an activator. An activator is necessary only if
you're creating a bundle and wish to specifically interact with OSGi API or need to per-
form custom initialization/de-initialization actions. If you're creating a simple library
bundle, it isn't necessary to give it an activator because it's possible to share class-
es without one.
 
Search WWH ::




Custom Search