Learning lifecycle - OSGi in Action - page 96

Plan ahead
Keep in mind that your bundle may be updated. Due to this possibility, you should
design your bundles so they properly deal with previously saved state, because
they may start with a private area from an older version of the bundle. The best ap-
proach is for your bundles to seamlessly migrate old state formats to new state
formats if possible. One tricky issue, though, is that the update lifecycle operation
may also be used to downgrade a bundle. In this case, your bundle may have diffi-
culty dealing with the newer state formats, so it's probably best if you implement
your bundles to delete any existing state if they can't understand it. Otherwise, you
can always uninstall the newer bundle first and then install the older version in-
stead of downgrading.

You could finish the history command, but let's try to make it a little more inter-
esting by keeping track of what's going on inside the framework. You can record
not only the issued commands, but also the impact they have on the framework.
The next section shows how you can achieve this using the framework's event-
notification mechanism.

3.3.5 Listening for events

The OSG i framework is a dynamic execution environment. To create bundles and,
ultimately, applications that are flexible enough to not only cope with but also take
advantage of this dynamism, you need to pay attention to execution-time changes.
The lifecycle layer API provides access to a lot of information, but it isn't easy to poll
for changes; it's much more convenient if you can be notified when changes occur. To
make this possible, the OSG i framework supports two types of events: BundleEvent s
and FrameworkEvent s. The former event type reports changes in the lifecycle of bun-
dles, whereas the latter reports framework-related issues.
You can use the normal Java listener pattern in your bundles to receive these
events. The BundleContext object has methods to register BundleListener and
FrameworkListener objects for receiving BundleEvent and FrameworkEvent notifica-
tions, respectively. The following listing shows how you implement the history
command. You record all executed commands as well as the events they cause dur-
ing execution.

Listing 3.12 Bundle and framework event listener example

package org.foo.shell;
import java.io.PrintStream;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import org.osgi.framework.BundleEvent;
import org.osgi.framework.BundleListener;