Moving toward bundles - OSGi in Action - page 204

b)

a)

Bundle-ClassPath: .,asm.jar Bundle-ClassPath: cglib.jar,asm.jar

CGLIB

CGLIB

Figure 6.4
Embedding tightly
coupled dependen-
cies in a bundle

ASM ASM

Alternatively, you can consider creating a new bundle artifact that embeds all the
related JAR files together instead of turning the primary JAR file into a bundle. This
aggregate bundle can then be provided separately to OSG i users without affecting
users of the original JAR files. Figure 6.4b shows how you can use this approach for the
CGLIB library. Although this means you have an extra deliverable to support, it also
gives you an opportunity to override or add classes for better interoperability with
OSG i. You'll see an example in a moment and also later on in section 6.2.1. This often
happens when libraries use external connections or background threads, which ide-
ally should be managed by the OSG i lifecycle layer. Such libraries are said to have state .

6.1.5 Adding lifecycle support

You may not realize it when you use a third-party library, but a number of them have a
form of state. This state can take the form of a background thread, a file system cache,
or a pool of database connections. Libraries usually provide methods to manage this
state, such as cleaning up resources and shutting down threads. Often, you don't
bother calling these methods because the life of the library is the same as the life of
your application. In OSG i, this isn't necessarily the case; your application could still be
running after the library has been stopped, updated, and restarted many times. On
the other hand, the library could still be available in the framework long after your
application has come and gone. You need to tie the library state to its bundle lifecycle;
and to do that, you need to add a bundle activator (see section 3.4.1).
The original HttpClient library from Apache Commons ( http://hc.apache.org/
httpclient-3.x/apidocs/index.html ) manages a pool of threads for multithreaded con-
nections. These threads are started lazily so there's no need to explicitly initialize the
pool, but the library provides a method to shut down and clean everything up:

MultiThreadedHttpConnectionManager.shutdownAll();
To w r a p t h e H t t p C l i e n t l i b r a r y JAR file up as a bundle, you can add an activator that
shuts down the thread pool whenever the HttpClient bundle is stopped. This
approach is as follows:

package org.apache.commons.httpclient.internal;

import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
import org.osgi.framework.*;

public class Activator implements BundleActivator {
public void start(BundleContext ctx) {}