Page History

...

4.2.2 Extended composite lifecycle management

To provide access to constituent bundles into the parent framework, the extended composite manager must proxy provided constituent bundles as separate virtual bundles in the parent framework. This complicates lifecycle management since it creates separate points of control for the composite bundle and it also complicates maintaining class space consistency for clients of the provided bundle. This section discusses these issues in more detail.

NOTE: Depending on how composite bundles are implemented, these issues may also apply to required bundles inside the composite bundle.

4.2.2.1 Two-phase resolve

When a composite providing access to a constituent bundle is first installed, the provided bundle cannot be made available immediately. Once the composite bundle is resolved (i.e., the composite's associated virtual module is injected with its wires), then the composite manager can install a virtual bundle proxying the provided bundle. At this point, the proxy provided bundle is available for use by other bundles in the parent framework, although it will still be in the installed state in the parent until someone actually causes it to resolve. However, resolving the proxy provided bundle technically has no real effect since it is actually resolved internal to the composite.

4.2.2.2 Maintaining class space consistency

If the packages exported by a provided bundle do not have uses constraints or if the uses constraints are confined to other packages exported by the provided bundle itself, then the proxying described in the last section is sufficient to provide access in the parent framework. On the other hand, if the provided bundle's exported packages have uses constraints on packages imported by the provided bundle, then this poses a potential issue for clients of the proxy provided bundle in the parent framework. The provided bundle's uses constraints must be modeled in the parent framework so it can maintain class space consistency.

To achieve this, when such a situation is detected, the composite manager must install an additional virtual bundle in the parent framework that acts as a uses constraint proxy bundle by exporting any packages imported by the provided bundle that are part of a uses constraint. Additionally, the proxy provided bundle must be generated such that it explicitly imports its packages from the uses constraint proxy bundle in the parent framework. This will ensure the parent framework correct observes the uses constraints and enforces them for potential clients. To clarify via an example, consider a composite description like this:

Bundle-ManifestVersion: 2
Bundle-Name: Paint Program
Bundle-SymbolicName: org.foo.paint.composite
Include-Bundle: \
 http://www.foo.org/httpservice.jar, \
 http://www.foo.org/javax.servlet.jar
Provide-Bundle: org.foo.http

Bundle-ManifestVersion: 2
Bundle-Name: HTTP Service
Bundle-SymbolicName: org.foo.http
Import-Package: javax.servlet, javax.servlet.http
Export-Package: org.foo.http; uses:="javax.servlet"

Bundle-ManifestVersion: 2
Bundle-Name: HTTP Service
Bundle-SymbolicName: org.foo.http
Import-Package: javax.servlet; bundle-symbolic-name="USES.12312"
Export-Package: org.foo.http; uses:="javax.servlet"

Bundle-ManifestVersion: 2
Bundle-Name: HTTP Service Uses Constraints
Bundle-SymbolicName: USES.12312
Export-Package: javax.servlet

Discuss: 1) two-phase nature 2) uses constraints and 3) lifecycle ops on provided bundles

...