The problems with dynamic imports don't stop there. Because dynamic imports
behave like optional imports at resolution time, there's no guarantee that the package
will be available to the running bundle. This means that your library must cope with the
possibility that one, some, or all of its dynamic imports won't be available at runtime!
Effectively, dynamic imports are a means of circumventing the modularity of your
bundle. If used properly, they're an invaluable tool, but for the most part they're best
Other problems that are more difficult to fix
The problems we've discussed so far have all had to do with modularization. Effectively,
the libraries rely on the relatively poor modularity of Java SE and suffer problems when
packaged as OSG i bundles. These sorts of problems can often (but not always) be fixed,
if only in a limited way, by careful packaging. A different class of problems are alto-
gether more unpleasant, though fortunately they're also much rarer. These are prob-
lems to do with bundle lifecycle and the structure of the framework itself.
URLS FOR CLASSPATH SCANNING
Some libraries attempt to do clever things by finding resources on the application's
classpath. Typically, they look for resources using a pattern, but crucially they don't
know the name of the resource before they find it. One example of this is if you wish
to find and run all classes that have a name ending in Test . To do this, the library typ-
ically looks for the root of the classpath by asking the classloader for the resource cor-
responding to "/" . Clearly, there are modularity problems here, but even if the library
found the correct root URL , there's another, bigger problem waiting.
When the framework has a root URL , it typically identifies it as either being a file:
or a jar: URL . After it has done this, it locates the directory or JAR on the filesystem, and
starts to list its contents, looking for matching files. The issue here is that OSG i doesn't
require the framework to have a fixed layout on the filesystem, or even be on disk at all!
The OSG i specification expects the framework to return URL s in a custom namespace.
This completely breaks any scanning performed by non- OSG i-aware libraries.
The only way around this sort of problem is to rewrite the library (or plug into it, if
you can) to be OSG i-aware when it's scanning. The only safe ways to scan bundles are
by using findEntries() on a Bundle or listResources() on a BundleWiring (the lat-
ter is only available on OSG i 4.3-compatible frameworks).
RESOURCE AND THREAD MANAGEMENT
If the library you're using creates its own threads or manages resources, for example
database connections, then it needs to correctly terminate or close them to prevent
erratic behavior and leaks. Given that many libraries are unaware of the OSG i lifecycle,
it's likely that the library won't respond to either being stopped, or uninstalled, cor-
rectly, and will probably leave orphaned threads or resources.
This sort of problem can also be demonstrated if clients are stopped, uninstalled,
or refreshed. Without proper resource management, the library can begin leaking
memory, or worse, hanging on to things related to bundles that no longer exist.
Search WWH ::