Question

According to the OSGi documentation, OSGi is designed to help prevent ClassPath problems.

For example, from “OSGi in action”:

ClassNotFoundExceptions when starting your application because the
class path wasn’t correct. OSGi can help by ensuring that code
dependencies are satisfied before allowing the code to execute.

However, since we’ve switched our java application to OSGi, I see more ClassNotFoundExceptions and especially NoClassDefFoundErrors than ever. Classes that were previously loading fine are not found anymore by the OSGI classloader, and worse: you get the error at run-time, which means that you can’t easily check for it except by manually testing every corner of your application.

For example, our application was running happily under OSGi, but we received reports from beta testers that they couldn’t export documents to PDF anymore. Indeed, when I looked into it, I found that this functionality caused an exception to be logged:

java.lang.NoClassDefFoundError: org/w3c/dom/Node

So, is OSGi actually creating more classpath problems than it solves?

and more importantly: How can I test that my class-path is consistent, with all necessary Import-Package statements etc. before I read about them in bug reports?

Answer 1

An OSGi application will not throw ClassNotFoundExceptions and NoClassDefFoundErrors if your manifest is correct. That is, you need to tell OSGi which packages your bundle uses; if you don’t do this correctly or honestly, then OSGi cannot help you. In other words: GIGO (Garbage In, Garbage Out).

For example, you use the package org.w3c.dom but you do not list it in your Import-Package statement. Therefore OSGi does not know that you need access to that package, and so when you actually try to load classes from that package, they are not available.

So, you need to make sure your Import-Package statement is accurate with respect to the packages your bundles actually use. The good news is that the “bnd” tool can do this for you by generating the bundle manifest, using bytecode analysis to find all the statically referenced packages.

Update:
Your final question asks how to test that your bundles are consistent before discovering problems at runtime. Bnd has a “verify” feature that does exactly this. Actually if you use Bnd to generate the manifest in the first place, then you will not need the verify feature. However, I don’t know anything about your build process so you might find it difficult to move to a Bnd-based build in the short term… in this case it would be relatively simple to add the verification task as a post-processing step after the build. However I would still recommend trying to use Bnd earlier in the build process.