1 Reply Latest reply on May 14, 2004 12:49 AM by juha

    Ear/War Classloader Question

    Mike Newbie

      Hi all,

      I am running 3.2.3, and I seem to have hit a brick wall at full speed!

      I have the following applications:

      A.war and B.ear. On their own, both applications deploy and function correctly. When both files are in the deploy directory, and the server starts up, the order of deployment is A, B. When I use application B, it is picking up a jar file, and configuration file from application A. I am assuming that this is due to the UnifiedClassLoader. I saw a few posts on disabling the UCL by including the loader-repository element in the jboss-app.xml file. I repackaged A into a file A.ear and added the following to the jboss-app.xml:


      This is where my nightmare begins. I get all kinds of ClassCastExceptions when I deploy A as an ear with the UCL disabled. I got passed some log4j errors by removing the log4j.jar from the a's Web-Inf/lib folder. I am now seeing all kinds of nasty XML errors. Apparently A uses JDom, and includes all kinds of Jdom, xerces, and jaxp jars in its web-inf/lib. (In case you can't tell, I wrote app B, and another team wrote app A. I'm the poor sap who gets to make it all work!)

      Am I on the right track by packaging application A as an ear file and disabling the UCL for both applications? Is there another, more pragmatic way to let two applications load their own jars, and not have classes leak between applications?

      Also, if some kind soul can explain, or point me to an appropriate thread/forum, how an app behaves when the loader-repository element is set.



        • 1. Re: Ear/War Classloader Question

          Before isolating the WAR files with the <loader-repository>, you could try setting UseJBossWebLoader property to false in deploy/jbossweb-tomcat/META-INF/jboss-service.xml file. This would isolate your WEB-INF directories per WAR while still leaving both standalone WARs in the same loader repository.

          However this may just be a temporary fix if your packages are depending on a lot of infrastructure libraries like log4j and JDom, as those may introduce incompatible API changes later on.