Webapp not deploying in glassfish when I have jars in the modules folder

Question

I have a Spring webapp running in Glassfish 3.1.2. I am just beginning to convert the webapp to OSGi. I undeployed the existing webapp and copied the spring and gemini OSGi jars into the modules directory in the Glassfish installation. I then installed and activated them using the Glassfish OSGi web console (which I understand to be some sort of customised Felix web console) and everything was fine. It didn't do anything but I could install and activate them in the web console which is what I wanted to test.

I then started to redeploy the non-OSGi jars of my existing webapp using the Glassfish Application console to see if the 2 type of jars could coexist, which, given my understanding of OSGi I thought they should be able to. At this point NoClassDefFoundErrors started getting thrown complaining about not being able to find org.apache.commons.logging amongst other classes. These class were present in both the Module directory as the installed OSGi jars and the application classpath. I then deactivated the jars in the console but didn't remove the the OSGi jars but the exceptions continued to be thrown.

I got a classloader print out and found that the jars in the WEB-INF of my webapp weren't getting loaded but I wasn't sure whether this was the problem or a symptom.

I then removed the jars from the uninstalled the OSGi jars and everything started working again and the webapp could be deployed.

Can anyone think of any reason why this might happen? I am guessing that the content of the module directory is on the classpath but if so why? How would I prevent this from causing problems if I want OSGi and non-OSGi jars to work together?

Side Notes

• When I viewed the classes getting loaded by the classloader I couldn't see content form the modules folder getting loaded.
• I can install and activate the OSGi jars after the the non-OSGi jars are deployed but not the other way round.

Answer 1

( Disclaimer: I do not have specific experience with glassfish, but JBoss and other strange environments sporting classloader hierarchies)

You have to be carefull with classloader hierarchies in java - the same bytecode equal class will not be equal or asignable to if comes from another classloader, and while loading classes it is important to find dependencies through loading classloader or his parents.

To resolve your situation you will have to carefully examine this hierarchy and check settings for delegation and class resolution ( like parent first / self first ).

JBoss tried to solve this problem by introducing unified classloader which resulted in one big pile of assorted classes and leaks of resources between contexts / webapps in default setting.