Dynamic content management

You typically install bundles into the runtime environment by listing them in the Subsystem-Content header of the feature manifest file. However, you can also dynamically add and remove OSGi bundles by installing a user-written bundle as part of the Subsystem-Content of a user-written feature. The user-written bundle obtains the OSGi bundle context to install and control additional bundles.

Note: In the following sections, the user-written feature is called UserFeatureA and the user-written bundle is called FeatureBundleA.

Installing, starting, stopping, and uninstalling bundles in Liberty

Installing bundles

You can write FeatureBundleA to obtain the OSGi bundle context, org.osgi.framework.BundleContext, by using one of the following methods:

Implement the BundleActivator interface, org.osgi.framework.BundleActivator. The BundleContext parameter of the start method is passed in by the OSGi framework, which is available to the user-written bundle when that bundle is activated. For more information on the BundleActivator interface, see Developing an OSGi bundle with simple activation.
Implement an available specification, such as OSGi Declarative Services or Blueprint, that provides access to the bundle context through another method or interface. For more information, see Composing advanced features by using OSGi Declarative Services and Blueprint bundles.

After FeatureBundleA obtains the bundle context, additional bundles can be installed by using either the installBundle(String location) or installBundle(String location, InputStream stream) methods.

Bundles that are dynamically installed resume state on a default restart. They do not persist across a clean start and require reinstallation. See Bundle caching for more details.

Starting bundles

If you want an installed bundle to be started, it is the responsibility of the installing bundle, FeatureBundleA, to call the start method for the bundle.

Stopping and uninstalling bundles

If the user-written feature, UserFeatureA, is removed from the server configuration, then FeatureBundleA is stopped and also uninstalled. Uninstallation of FeatureBundleA triggers uninstallation of all the bundles that were installed by FeatureBundleA, if they are not already uninstalled. The org.osgi.framework.Bundle.uninstall() method is called for each bundle, which stops and uninstalls it. This uninstallation process also applies if FeatureBundleA is uninstalled by any other means.

If UserFeatureA is removed from the server configuration when the server is stopped, the bundles that were installed by UserFeatureA are removed on the next server start. If the start levels of the bundles are unmodified from their defaults, the bundles are removed before they are restarted . If the start levels of the bundles were modified, they might not be removed until after they have restarted.

Other lifecycle management tasks are done by FeatureBundleA according to the OSGi core specification, by using the org.osgi.framework.Bundle and org.osgi.framework.BundleContext interfaces.

Bundle caching, package visibility, and programming model support in Liberty

Bundle caching

When the server is shut down, all the currently installed bundles are stopped and OSGi metadata is persisted to a bundle cache. On a default start, these installed bundles are returned to their previous state. On a clean start, any bundles that were installed by FeatureBundleA have their persistent data deleted. As a result, on a clean start these bundles are not resumed. FeatureBundleA itself is resumed because it is reinstalled by the feature manager, provided UserFeatureA is still in the server configuration. If you want to reinstall any bundles after a clean start, it is the responsibility of FeatureBundleA to do the reinstallation. You are not notified about a clean start, but you can check whether a bundle is installed by using the OSGi

BundleContext
getBundle(String location)

method.

Package visibility

Bundles that are dynamically installed, and are not listed in the Subsystem-Content header of the feature manifest file, have the following visibility:

Dynamically installed bundles can import any API and SPI packages provided by the currently configured set of features.
Packages that are exported by other bundles within the same product extension that are not declared as API or SPI, are not visible to dynamically installed bundles.
Packages that are exported from dynamically installed bundles cannot be declared as API or SPI.
There are no restrictions on importing packages that are exported from dynamically installed bundles.

Programming model support

Dynamically installed bundles can use implementations of OSGi enterprise specifications provided that the appropriate runtime features are configured to enable them.