Learning lifecycle - OSGi in Action - page 99

■ BundleEvent.STARTING —Indicates a bundle is about to be started
■ BundleEvent.STOPPING —Indicates a bundle is about to be stopped
Synchronous bundle listeners are sometimes necessary (as you'll see in the paint
example in the next section), but should be used with caution. They can lead to con-
currency issues if you try to do too much in the callback; as always, keep your callbacks
as short and simple as possible and don't call foreign code while holding a lock. In all
other cases, the thread invoking the listener callback method is undefined. Events
become much more important when you start to write more sophisticated bundles
that take full advantage of the bundle lifecycle.

3.3.6 Bundle suicide

We've mentioned it numerous times: a bundle isn't supposed to change its own state.
But what if a bundle wants to change its own state? Good question. This is one of the
more complicated aspects of the lifecycle layer, and there are potentially negative
issues involved.
The central issue is that if a bundle stops itself, it finds itself in a state it shouldn't
be in. Its BundleActivator.stop() method has been invoked, which means its bun-
dle context is no longer valid. Additionally, the framework has cleaned up its book-
keeping for the bundle and has released any framework facilities it was using, such as
unregistering all of its event listeners. The situation is even worse if a bundle tries to
uninstall itself, because the framework will likely release its class loader. In short, the
bundle is in a hostile environment, and it may not be able to function properly.
Because its bundle context is no longer valid, a stopped bundle can no longer use
the functionality provided by the framework. Most method calls on an invalid bundle
context will throw IllegalStateException s. Even if the bundle's class loader is
released, this may not pose a serious issue if the bundle doesn't need any new classes,
because the class loader won't be garbage collected until the bundle stops using it. But
you're not guaranteed to be able to load new classes if the bundle was uninstalled. In
this case, the framework may have closed the JAR file associated with the bundle. Already-
loaded classes continue to load, but all bets are off when attempting to load new classes.
Depending on your bundle, you may run into other issues too. If your bundle cre-
ates and uses threads, it's typically a good idea for it to wait for all of its threads to
complete when its BundleActivator.stop() method is called. If the bundle tries to
stop itself on its own thread, that same thread can end up in a cycle waiting for other
sibling threads to complete. In the end, the thread waits forever. For example, the sim-
ple shell uses a thread to listen for telnet connections and then uses secondary
threads to execute the commands issued on those connections. If one of the second-
ary threads attempts to stop the shell bundle itself, it ends up waiting in the shell bun-
dle's BundleActivator.stop() method for the connection thread to stop all of the
secondary threads. Because the calling thread is one of the secondary threads, it'll
end up waiting forever for the connection thread to complete. You have to be careful
of these types of situations, and they're not always obvious.