Java Reference
In-Depth Information
import a package that's unknown when the bundle manifest is created. This is one of
the most useful features of the DynamicImport-Package header:
DynamicImport-Package: fancyfoods.*
In the above example, see how you can import any package that starts with fancy-
foods. into your bundle. You could be even more general and import any package
using * with no prefix. As with normal package imports, you can add version ranges
and attributes to your imports.
DYNAMICIMPORT-PACKAGE AND LOGGING
You can use dynamic imports to help you with your logging library. If you think back
to the problems we discussed, many of them were related to class and resource load-
ing. If you add a DynamicImport-Package: * header to your logging API , then you
no longer need to worry about all of the unpleasant imports for various logging
implementations. In this case, the implementations can be wired dynamically as
they're loaded.
Dynamic imports can also help you with configuration and custom implementa-
tions. As long as the package containing the configuration file or custom class is
exported, then there will be no problem loading that either. Dynamic imports seem to
be the wonder solution to your logging problems! Unfortunately, this isn't the case.
There are a number of significant problems.
THE PROBLEMS WITH DYNAMIC IMPORTS
Dynamic imports are extremely powerful, but are also over-used. It may be hard to
imagine how dynamic imports could be a problem at first, but there's one example
that clearly shows how DynamicImport-Package is a poor way to load resources.
Assume that your logging library expects to find configuration in the file
META-INF /logging-config.xml. In this case, you would need to export META-INF as a
package from the client bundle and dynamically import it using either Dynamic-
Import-Package: * or DynamicImport-Package: META-INF . Let's start by consider-
ing DynamicImport-Package: * . Although it's fun to use, because it requires little
thought on the part of the person writing the bundle, the performance and modu-
larity implications are bad. Any time a resource is loaded, OSG i's nicely structured
classpath is turned into a big, slow, flat classpath. Searching this classpath is slow . Fur-
thermore, the resource could end up being loaded from anywhere —you've bypassed
all of OSG i's explicit dependency management. DynamicImport-Package: META-INF
is a little bit nicer, but it still doesn't scale well to multiple client bundles. Which
META-INF will you wire to? How do you version it sensibly? When the package is
wired, either you'll get a random configuration file, which would be disastrous, or, if
you select the right bundle using attributes, your logging implementation is tied to
exactly one client! Even in the case where you don't have to export META-INF , you
still end up in a situation where you can only wire to one bundle for the package,
something that's never going to cope with multiple versions of the same bundle in
the runtime.
Search WWH ::




Custom Search