These problems can be extremely difficult to fix, but in some cases it can be
enough to add an Activator class to your bundle (see appendix A) and manifest. If
this class is used to perform necessary cleanup when the library is stopped, then it can
prevent the leakage that would otherwise occur.
In this chapter, we've taken an extensive look at how libraries developed for standard
Java can be used in OSG i. We don't intend this chapter to be a cautionary tale,
although most of the difficulties we describe here are used as reasons why OSG i is too
hard or broken . For the most part, libraries converted to run in OSG i can be used with-
out any intervention or special effort; it's merely unfortunate that some commonly
used libraries suffer from the majority of the problems.
We hope that, having read this chapter, you understand how easy it is to take a JAR
and package it as an OSG i bundle, preferably using a combination of tooling and
hand-finishing. Although this isn't always the end of the story, for many libraries this is
all you need to do.
If you're unlucky enough to come across problems after converting your library,
we hope that you also feel confident enough to work through them. Some of the class-
loading problems that appear can be hairy, but most can be avoided or fixed with a lit-
tle intelligence and some judiciously applied packaging changes.
Now that you've seen how to pull libraries into OSG i, even when they weren't orig-
inally written to use it, you've reached an advanced level of knowledge. You've
reached the point where your OSG i knowledge is sufficient for you to start building
your own runtimes. In the next chapter, we'll look at doing exactly that: comparing
the features offered by a range of prepackaged runtimes with those that you can
piece together yourselves.
Search WWH ::