Gangmax Blog


Unit-testing OSGi Code With pax.exam

| Comments

In the past recent days I was working on unit-testing OSGi code with pax.exam package. Here’s some hints I got.

When running the unit test code, if you find the very first class invocation of your tested OSGi bundle reports the “ClassNotFoundError”, most likely the reason is that your OSGi bundle’s required packages are not all included in the pax container, which makes your OSGi bundle is not loaded properly, too.

If the tested OSGi bundle adds new “Require-Bundle” bundle item, the required bundle should be included in the “pax.exam” running environment. A worse thing is: if you add bundle “A”, bundle “A” depends on bundles “B”, “C”, “D”, bundle “B” depends on bundles “E”, “F”, … That’s really a very bad thing to figure out what’s the full dependency list of bundle “A”.

Then I create a Ruby program to do such things: parse the “META-INF/METAINFO.MF” file of a given OSGi bundle and check whether the depended bundles are in my library, if it’s not, parse each depended bundle recursively, to figure out all the missing bundles.

One exception is “org.eclipse.osgi_xxx.jar”(in my case it’s “org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar”). This bundle should be treated as normal library jar which is used to start the OSGi container, not as an OSGi bundle to be loaded into the OSGi container. If you do so, you’ll get exception when starting the test case with some kind of “Serializable” exception.

gist 5159938

One hint: if the tested OSGi bundle depends on bundle A, while you’re sure the bundle A will not be used in your test cases, you can modify the bundle A’s “MENIFAST.MF” file by removing the “required-bundle” line. By doing this, you don’t need to analysis all the depended bundles of bundle A, it makes a much simpler solution.