Page History

...

After a composite bundle is stopped, it should remain resolved and continue to provide access to its exported packages and provided bundles.

NOTE: Since this proposal does not propose an API to expose the constituent bundles, individual lifecycle manipulation of the constituent bundles is not expected. To keep things simple, constituent bundles are either active or not based on the state of their composite bundle. If more fine-grained control is required it would be possible. Starting and stopping individual constituent bundles would offer no real issue, although allowing them to be refreshed or uninstalled might cause the composite manager to force the outer composite bundle to refresh if the export signature is impacted.

4.1.2.5

...

Updating a composite

When refreshing a composite bundle , all constituent bundles are refreshed and the composite bundle returns to the installed state. Following normal framework behavior, any bundles depending on the composite bundle will also be refreshed. Likewise, if the composite bundle depends on another bundle being refreshed in the parent framework, then it will be refreshed toois updated, the composite manager must continue to support the associated virtual module; i.e., it must still be possible to load classes from it. At the point in time when the bundle is refreshed and returned to the installed state, then the composite manager can dispose of the old virtual module. If the composite was updated to a normal bundle (or a different kind of virtual bundle), then the composite manager will no longer manage it. On the other hand, if was updated to another composite bundle, then the composite manager will reinstall a new virtual module for it.

4.1.2.6 Uninstalling a composite

The normal bundle uninstall operation When a bundle is uninstalled, that does not directly mean that a bundle it is no longer in use by the framework, since it is must still be possible to load classes from it. FurtherUnfortunately, the framework provides to no additional callbacks or state changes to notify when it is really done with a an uninstalled bundle. As a result, if a composite bundle is uninstalled, the composite manager must immediately refresh it to perform proper clean up, since it will not be able to get a later lifecycle callback when the uninstalled bundle is eventually refreshed.

NOTE: This could be improved with a VirtualModule.dispose() method, which would be invoked by the framework to indicate when it was done with the virtual module.

4.1.2.7 Refreshing a composite

When refreshing a composite bundle, all constituent bundles are refreshed and the composite bundle returns to the installed state. Following normal framework behavior, any bundles depending on the composite bundle will also be refreshed. Likewise, if the composite bundle depends on another bundle being refreshed in the parent framework, then it too will be refreshed.

4.1.2.8 Relationship to composite manager lifecycle

Since the composite manager manages all aspects of the composite's content, its active lifetime scopes its managed composites. In other words, if the composite manager is stopped, then it explicitly causes all of its managed composites to refresh and return to the installed state.

...