Java Reference
In-Depth Information
bundle can be successfully resolved even if there isn't an
org.osgi.service.log
pack-
age available. Attempts by the bundle to use classes from this package at execution time
result in
ClassNotFoundException
s. All imported packages have a resolution associated
with them, but the default value is
mandatory
. We'll look at how this is used in practice
in section 5.2.4, but for now let's consider the other tool in the box: dynamic imports.
5.2.2
Dynamic imports
Certain Java programming practices make it difficult to know all the packages that a
bundle may need at execution time. A prime example is locating a
JDBC
driver. Often
the name of the class implementing the
JDBC
driver is a configuration property or is
supplied by the user at execution time. Because your bundle can only see classes in
packages it imports, how can it import an unknown package? This sort of situation
arises when you deal with service provider interface (
SPI
) approaches, where a com-
mon interface is known in advance, but not the name of the class implementing it. To
capture this,
OSG
i has a separate
DynamicImport-Package
manifest header.
DYNAMICIMPORT-PACKAGE
This header is a comma-separated list of packages
needed at execution time by internal bundle code from other bundles, but
not needed at resolve time. Because the package name may be unknown, you
can use a
*
wildcard (matching all packages) or a trailing
.*
(matching sub-
packages recursively).
You may have expected from the previous examples that dynamic imports would be
handled using an import directive rather than their own manifest header, but they're
sufficiently different to warrant a separate header. In the most general sense, a
dynamic import is expressed in the bundle metadata like this:
DynamicImport-Package: *
This snippet dynamically imports any package needed by the bundle. When you use
the wildcard at the end of a package name (for example,
org.foo.*
), it matches all
subpackages recursively but doesn't match the specified root package.
Given the open-ended nature of dynamic imports, it's important to understand
precisely when in the class search order of a bundle they're employed. They appear in
the class search order as follows:
Requests for classes in
java.
packages are delegated to the parent class loader;
searching stops with either a success or failure (section 2.5.4).
1
Requests for classes in an imported package are delegated to the exporting
bundle; searching stops with either a success or failure (section 2.5.4).
2
The bundle class path is searched for the class; searching stops if found but con-
tinues to the next step with a failure (section 2.5.4).
3
If the package in question isn't exported by the bundle, requests matching any
dynamically imported package are delegated to an exporting bundle if one is
found; searching stops with either a success or failure.
4
