Debugging applications - OSGi in Action - page 282

to the framework implementers. This example uses Apache Felix, which leaves the
default TCCL unchanged; in other words, it'll be set to the application class loader.
Unfortunately, the application class loader has no visibility of the Auditor class con-
tained within the test bundle, which explains why you see a ClassNotFoundException .
To avoid this exception, you need to update the TCCL in the test bundle before
sending the message. To be consistent, you should also record the original TCCL and
reset it after the call completes. This last step is important if you want to nest or share
containers inside the same process, as you saw in figure 8.13. Look at the test activator
contained under org.foo.hub.test ; following are the changes needed to set and
reset the TCCL .
Listing 8.5 Setting and resetting the TCCL
public Object addingService(ServiceReference reference) {
ClassLoader oldTCCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(
getClass().getClassLoader());
Hub hub = (Hub) ctx.getService(reference);
hub.send(new TextMessage(".*", "Testing Testing 1, 2, 3..."));
} catch (Throwable e) {
e.printStackTrace();
} finally {
Thread.currentThread().setContextClassLoader(oldTCCL);
}
return null;
}
This listing saves the old TCCL , sets the new TCCL , and then restores the old TCCL .
With these three changes, you can rerun the test without any class-loading problems:
$ ./chapter08/classloading/PICK_EXAMPLE 7
Fri Sep 19 00:13:52 SGT 2009 - org.foo.spoke.SpokeImpl@186d4c1
RECEIVED Testing Testing 1, 2, 3...
That wraps up our discussion of class-loading problems. You used the same example
code to see a wide range of different exceptions you may encounter when developing
OSG i applications. We hope this will provide you with a foundation for any future
class-loading investigations. If you can relate a particular exception with one of the
examples here, the associated solution will also help fix your problem.
Unfortunately, class loading isn't the only problem you'll encounter when working
with OSG i, but the next topic we'll look at is indirectly related to class loading. OSG i
enforces modularity with custom class loaders. An OSG i application contains several
class loaders, each one holding on to a set of resources. Unused class loaders are freed
as bundles are uninstalled and the framework is refreshed, but occasionally a rogue
reference keeps a class loader and its associated resources alive. This can turn into a
memory leak.