Bundle auto-refreshing mechanism and handling depending bundles.

Bundle auto-refreshing

Framework supports a mechanism of auto refresh when a bundle is "installed from file" (refer to the Storage-related functionality section in the Framework access service document).

This mechanism is activated, when the bundle archive in the original file location is updated, while the framework is shutdown. On the next framework restart its manifest, native libraries and sub-archives (as described in the Bundle-Classpath manifest header) are re-extracted to make sure that the new content of the bundle is applied.

When the framework is restarted, and after the FrameworkEvent.STARTED and BundleEvent.STARTED for the system bundle are fired, a BundleEvent.UPDATED (for the bundle with the modified bundle archive) is fired. This mechanism allows interested management applications to "observe" such changes in the framework as normal bundle updates.

A WARNING message indicates that a modified bundle archive was detected during the framework restart.

Example for a detected modified bundle archive:

#0 WARNING > Bundle Archive Replaced, refreshing: ../../../bundles/com.prosyst.mbs.osgi.eventadmin.jar

Handling depending bundles

When a bundle is updated or uninstalled, there are two ways to handle the bundles that depend on it (bundles that import packages from this bundle):

• Eager update/uninstall – All dependent bundles are stopped recursively, their class loaders are removed and their state is set to INSTALLED. After restarting the updated bundle, an attempt will be made to resolve and restart all dependent bundles.
• Lazy update/uninstall – All packages exported by the bundle are kept, the bundle's class loader becomes a "zombie" class loader. Later you can eagerly remove the zombies by calling refreshPackages on the Package Admin service.

The update mode can be changed at runtime from the framework console through the updatemode command (check Management via text console).