Learning lifecycle - OSGi in Action - page 100

Under normal circumstances, you shouldn't try to stop, uninstall, or update your
own bundle. OK —that should be enough disclaimers. Let's look at a case where you
may need to do it anyway. We'll use the shell as an example, because it provides a
means to update bundles, and it may need to update itself. What do you have to do to
allow a user to update the shell bundle via the shell command line? You must do two
things to be safe:

Use a new thread when you stop, update, or uninstall your own bundle.

1

Do nothing in the new thread after calling stop, update, or uninstall.

2

You need to do this to prevent yourself from waiting forever for the shell thread to
return when you get stopped and to avoid the potential ugliness of the hostile envi-
ronment in which the thread will find itself. The following listing shows the changes
to the implementation of the stop command to accommodate this scenario.

Listing 3.13 Example of how a bundle can stop itself

package org.foo.shell;

import java.io.PrintStream;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleException;

class StopCommand extends BasicCommand {
public void exec(String args, PrintStream out, PrintStream err)
throws Exception {
Bundle bundle = getBundle(args);

if (bundle.equals(m_context.getBundle())){
new SelfStopThread(bundle).start();
} else {
bundle.stop();
}
}

Gets reference to
bundle representation

B

private static final class SelfStopThread extends Thread {
private final Bundle m_self;

public SelfStopThread(Bundle self) {
m_self = self;
}

public void run() {
try {
m_self.stop();
} catch (BundleException e) {
// Ignore
}
}
}
}
You use the BundleContext.getBundle() method to get a reference to the bundle
representation and compare it to the target bundle B . When the target is the shell

C

Executes
Bundle.stop()