1 Reply Latest reply on Nov 20, 2006 1:29 PM by ssilvert

    Classloader advice, WAR troubles, and the like...

    mbabauer

      My team is in the process of refactoring a lot of our code to run on JBoss 4.0.5. We currently deploy to JBoss 3.2.5.

      As we all know, there was a huge paradigm shift in class loading between the 3.x and 4.x JBoss versions. The older versions used a flat class loader, or one typically referred to as the "Unified" class loader, since everything could see everything. Now, a hierarchical class loader is used, as this promotes deployment isolation, which is a good thing.

      In the past, my group has utterly taken advantage of the fact there was a Unified class loader. We wrote code with the knowledge that every class was universally visible. We threw all our JAR libs into the jboss lib dir. We did all the things that people say you shouldn't do. As we have several "modules" to the overall application, each with its own set of requirements and such, this bit us several times, especially with library classes. As part of this refactor, we are 100% committed to fixing these issues.

      Here in lies our delima. The problem exists when we try to deploy any WAR units that have libraries inside WEB-INF/lib. These libraries are visible to the WAR classes, but do NOT appear visible to Tomcat. Since we use things like Struts and JSF, this has posed a huge problem. The problem is that as soon as Tomcat tries to run any of our action classes, it dies with a NoClassDefFoundError. We are seeing this all over, and the only solution we have right now is to force the use of a unified class loader, thusly defeating the purpose of isolation.

      How does one ensure class and library isolation but allow visibility of these needed classes without resorting to just throwing the JAR libraries into the lib dir or switching back to a flat, unified class loader?