Java Reference
In-Depth Information
■
FrameworkEvent.WARNING
—Indicates a warning. Not crucial, but may indicate a
potential error.
■
FrameworkEvent.ERROR
—Indicates an error. Requires immediate attention.
■
FrameworkEvent.PACKAGES_REFRESHED
—Indicates the framework has refreshed
some shared packages. We'll discuss what this means in section 3.5.
■
FrameworkEvent.STARTLEVEL_CHANGED
—Indicates the framework has changed
its start level. We'll discuss what this means in chapter 10.
The wrapper also implements the single
BundleListener.bundleChanged()
method.
Here, you also record the event information in the history list. Bundle events have one
of the following types:
■
BundleEvent.INSTALLED
—Indicates a bundle was installed
■
BundleEvent.RESOLVED
—Indicates a bundled was resolved
■
BundleEvent.STARTED
—Indicates a bundle was started
■
BundleEvent.STOPPED
—Indicates a bundle was stopped
■
BundleEvent.UPDATED
—Indicates a bundle was updated
■
BundleEvent.UNINSTALLED
—Indicates a bundle was uninstalled
■
BundleEvent.UNRESOLVED
—Indicates a bundle was unresolved
You register the listeners using the bundle context as follows:
private void addListener(BundleContext context,
BundleListener bundleListener, FrameworkListener frameworkListener) {
context.addBundleListener(bundleListener);
context.addFrameworkListener(frameworkListener);
}
The example doesn't show how to remove the listeners, which requires calls to the
removeBundleListener()
and
removeFrameworkListener()
methods on the bundle
context. It's not necessary to remove the listeners, because the framework will do so
automatically when the bundle is stopped; this makes sense because the bundle con-
text is no longer valid after the bundle is stopped. You only need to explicitly remove
your listeners if you want to stop listening to events while your bundle is active.
For the most part, the framework delivers events asynchronously. It's possible for
framework implementations to deliver them synchronously, but typically they don't
because it complicates concurrency handling. Sometimes you need synchronous
delivery because you need to perform an action as the event is happening, so to speak.
This is possible for
BundleEvent
s by registering a listener implementing the
Synchro-
nousBundleListener
interface instead of
BundleListener
. The two interfaces look
the same, but the framework delivers events synchronously to
SynchronousBundle-
Listener
s, meaning the listener is notified during the processing of the event. Syn-
chronous bundle listeners are processed before normal bundle listeners. This allows
you to take action when a certain operation is triggered; for example, you can give
permissions to a bundle at the moment it's installed. The following event types are
only sent to
SynchronousBundleListener
s:
