10.1. Removing Phantom Bundles

Earlier we learned that the exported packages remain in effect even when the exporting bundle has been updated, stopped, or uninstalled. Although this behavior is deterministic, it does leave behind “zombies”—inaccessible bundles that consume valuable resources. The following user session reveals this situation:

> start jes_path/bundles/log.jar, jes_path/bundles/device.jar
> bundles
ID  STATE   LOCATION
--  ------  ----------------------------
0   ACTIVE  System Bundle
1   ACTIVE  file:jes_path/bundles/log.jar
2   ACTIVE  file:jes_path/bundles/device.jar
> exportedpackages
Package: org.osgi.service.device (0.0.0)
  Exported by: 2 (file:jes_path/bundles/device.jar)
  Imported by: 2 (file:jes_path/bundles/device.jar)
Package: org.osgi.service.log (1.0.0)
  Exported by: 1 (file:jes_path/bundles/log.jar)
  Imported by: 1 (file:jes_path/bundles/log.jar)
            2 (file:jes_path/bundles/device.jar)

The device bundle imports the org.osgi.service.log package from the Log bundle. After both bundles were resolved and started, we witnessed that this is indeed so from the exportedpackages command output.

We next uninstall the Log bundle and reexamine the exported packages:

> uninstall 1
> exportedpackages
Package: org.osgi.service.device (0.0.0)
  Exported by: 2 (file:jes_path/bundles/device.jar)
  Imported by: 2 (file:jes_path/bundles/device.jar)
Package: org.osgi.service.log (1.0.0)
 Exported by: 1 (file:jes_path/bundles/log.jar)
  Imported by: 2 (file:jes_path/bundles/device.jar)

Although the Log bundle has been uninstalled, the line of exportedpackages output in bold type shows that its packages remain exported as before.

Finally, we reinstall and restart the Log bundle.

In Figure 10.1, a new bundle ID (3) was assigned to the installed and restarted Log bundle. The highlighted part of the exportedpackages output shows that the uninstalled Log bundle, whose ID is 1, still hangs around: The Device bundle imports the org.osgi.service.log package from bundle 1, and so does the newly activated Log bundle 3 because its package export attempt was blocked because of bundle 1.

This situation is not optimal. Bundle 1 is a phantom because it does not appear in the bundles output and is not usable anymore. Bundle 3 is fully capable of taking over and exporting the needed packages. Even worse, it may be offering a newer version of the log package after bug fixes for export, but is not given a chance to do so. With the OSGi 1.0 framework, one has to relaunch the framework to clean up the likes of bundle 1. Work is under way to provide a mechanism that allows an administrator to perform the cleanup without necessarily shutting down the framework.