Page History

...

Bundle-ManifestVersion: 2
Bundle-Name: PaintHTTP ProgramComposite
Bundle-SymbolicName: org.foo.paintcomposite.compositehttp
Include-Bundle: \
 http://www.foo.org/httpserviceorg.foo.http.jar, \
 http://www.foo.org/javax.servlet.jar
Provide-Bundle: org.foo.http

This composite contains two constituent bundles and provides access to the org.foo.http constituent bundle. Assume the org.foo.http bundle has the following metadata:

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"

, org.foo.http.util

In this case the org.foo.http

...

imports two packages (javax.servlet and javax,servlet.http), presumably both come from the other constituent bundle in the composite, and exports two packages (org.foo.http and org.foo.http.util), where org.foo.http has a uses constraint on the imported javax.servlet package. To properly proxy this provided bundle, the composite manager would install a virtual bundle in the parent framework that looked like this:

Bundle-

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

Bundle-SymbolicName: org.foo.http
Import-Package: javax.servlet; bundle-symbolic-name="USES.12312"
Export-Package: org.foo.http; uses:="javax.servlet", org.foo.http.util

This proxy provided bundle enables access to the exported packages of the original provided bundle and correctly models its uses constraints on a second uses constraint virtual bundle. The composite manager generates the proxy provided bundle metadata so that it can only resolve to the generated uses constraint virtual bundle, which would look something like this:

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

Since there is no uses constraint on the javax.servlet.http package, then it need not be provided by the uses constraint bundle. On the other hand, if there was then it would need to be exported as well. Further, if these exported packages had uses constraints on other imported packages, then these would need to be modeled as well. However, these could be modeled by simply having the uses constraint bundle export them in addition to the original exports (effectively reexporting the imported packages).

NOTE: The approach to proxy the provided bundle as two bundles (the proxy bundle and the uses constraint bundle) is necessary to maintain the semantics of Require-Bundle which only gives access to the target bundle's exported packages. A different, but not completely consistent approach is to just proxy the provided bundle and turn all of its imports into exports so that all uses constraints are satisfied by the proxy itself. The main downside of this approach is that client bundles in the parent framework would end up with greater visibility of packages than if they required the bundle directly.

If a composite provides multiple bundles, then shared and potentially conflicting packages among the provided bundles would need to be correctly modeled. For each provided bundle, a package space would need to be calculated for any imported package participating in a uses constraint. Any common packages with the same provider among the provided bundles would need to be modeled on a common uses constraint bundle in the parent framework, where the same package coming from different providers would need to be modeled with a separate uses constraint bundles. Non-overlapping packages could be lumped into a single uses constraint bundle. This algorithm would be non-trivial, but since it is just walking existing wires, it should not suffer from similar performance issues like the resolver algorithm.

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

...