Java Reference
In-Depth Information
4 The environment queries the repository and finds one match. Even though
bundle B at version 1.0.0 and at version 1.1.0 both look like possible matches,
the mandatory directive on version 1.1.0 of B means that the requirement
doesn't match (because it doesn't specify type=old ). Because of this, the repos-
itory returns fancyfoods.pkg exported at version 1.1 from B at version 1.0.0.
5 Neither A nor B has any further requirements. The resolver continues to pro-
cess the Test bundle.
6 The resolver queries the environment for the second package import from the
Test bundle. The environment has no local matches and queries the reposi-
tory, which also returns no matches because there are no bundles exporting the
fancyfoods.z package. Rather than fail the resolution at this stage, the resolver
determines that the import is optional and doesn't need to be satisfied for this
resolution to be valid.
7 The resolver reports that the Test bundle can be successfully resolved, and that
it requires both bundle A at version 1.0.0 and bundle B at version 1.0.0 to do so.
After you've determined that the necessary bundles required to make Test resolve are
A and B at version 1.0.0, then the provisioner can ask the repository where the bundles
are located and download them. If Test were the core content of an application, then
you'd now have successfully determined the shared content you need to deploy it!
Packages have a rather special place in OSG i because they represent the unit of modu-
larity. The problem with Java packages, however, is that they aren't particularly well-
defined units. On one level, a package is easy to define: every class declares which
package it's in. But overlaps between packages exist. Methods on an interface in one
package can accept parameters, or return things, that are declared in another pack-
age. This causes a problem for you in OSG i.
The identity of a class is determined by two things: its fully qualified name and the
ClassLoader that loaded it. Because each bundle has its own classloader, but also
imports classes from other bundles, it's possible that a class will exist more than once in
a framework, but none of them will be the same class! Normally this isn't a problem,
because the resolver ensures that you're only wired to a consistent set of bundles, but
what if one of the packages you imported returned you an object from a different pack-
age? You would need to be certain that your view of that object was the same as the one
from the imported package. If it wasn't, you would get a ClassCastException !
This is where the uses clause comes in. The uses directive can be applied to
almost any header, but it's most often applied to Export-Package entries. It tells the
framework about the other packages that are used by the exported package. This may
mean that the exported package has method parameters or return values from those
packages, or that they're used internally by classes in the package in a way that might
cause problems. The directive instructs the resolver that when someone imports this
package, the user must share the same class space for all of the packages in the uses
directive, as shown in listing 7.3.
Search WWH ::

Custom Search