1 Reply Latest reply on Apr 11, 2007 8:59 PM by Steve Corwin

    JBoss 4.0.4 using UnifiedClassLoader despite config

    Steve Corwin Newbie

      We're using JBoss 4.0.4 on Linux and OSX. We have it configured to not use the UnifiedClassLoader, but it still does for some of our classes. My immediate problem is that I'm catching an EJBException in my web app, and I want to get the exception contained in the EJBException and cast it to one of our custom exceptions so I get to the extra data in the custom exception. However the EJBException and the exception it contains are loaded by the UnifiedClassLoader and the web app code is loaded by the WebappClassLoader, so I get a ClassCastException when I try it.

      Our ear file contains a jboss-app.xml, which contains this:

      <jboss-app>
       <loader-repository>
       com.shopzilla:loader=shoppingcart.ear
       <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository>
      </jboss-app>


      Our war file contains a jboss-web.xml, which contains this:
      <jboss-web>
       <class-loading java2ClassLoadingCompliance="false">
       <loader-repository>
       com.shopzilla:loader=samples.war
       <loader-repository-config>
       java2ParentDelegation=false
       </loader-repository-config>
       </loader-repository>
       </class-loading>
      </jboss-web>


      I deployed those files and restarted JBoss to make sure they took effect. Now when I go to the JMX Console I see the loaders:
      com.shopzilla
       * loader=samples.war
       * loader=shoppingcart.ear

      but I still get the ClassCastException.

      I tried changing my ear-deployer.xml to this:
      <server>
       <!-- EAR deployer, remove if you are not using ear deployments -->
       <mbean code="org.jboss.deployment.EARDeployer"
       name="jboss.j2ee:service=EARDeployer">
       <!-- A flag indicating if ear deployments should have their own scoped
       class loader to isolate their classes from other deployments.
       -->
       <attribute name="Isolated">true</attribute>
       <!-- A flag indicating if the ear components should have in VM call
       optimization disabled.
       -->
       <attribute name="CallByValue">true</attribute>
       </mbean>
      </server>

      and restarting JBoss, but that didn't help either.

      I added some println()s to see the classloaders.
      System.out.println("ee.getCausedByException().getClass().getClassLoader(): " + ee.getCausedByException().getClass().getClassLoader());

      produces
      09:29:04,822 INFO [STDOUT] ee.getCausedByException().getClass().getClassLoader(): org.jboss.mx.loading.UnifiedClassLoader3@1f5205c{ url=file:/home/scorwin/apps/jboss-4.0.4.GA/server/shoppingcart/tmp/deploy/tmp38558shoppingcart.ear ,addedOrder=42}

      ee is an EJBException, so that's why I think that it's being loaded by the UnifiedClassLoader.
      If I create an instance of my custom exception named uaeeFoo,
      UsernameAlreadyExistsException uaeeFoo = new UsernameAlreadyExistsException("fubar");
      System.out.println("uaeeFoo.getClass().getClassLoader(): " + uaeeFoo.getClass().getClassLoader());

      produces
      09:29:04,823 INFO [STDOUT] uaeeFoo.getClass().getClassLoader(): WebappClassLoader
       delegate: false
       repositories:
       /WEB-INF/classes/
       ----------> Parent Classloader:
       java.net.FactoryURLClassLoader@d5f9b9


      Is there some setting I missed that would cause it to ignore my other settings and keep using the UnifiedClassLoader?

        • 1. Re: JBoss 4.0.4 using UnifiedClassLoader despite config
          Steve Corwin Newbie

          We did finally get something working. The secret was to upgrade to JBoss 4.0.5, and, when installing it, to enable "deployment isolation/call by value". I'm not sure if upgrading was really necessary or just installing JBoss 4.0.4 with "deployment isolation/call by value" enabled would have done it - a coworker tried reinstalling 4.0.4 and reported that it didn't work, then realized he'd made a mistake, and we didn't have time to try again.

          It appears that the changes to jboss-app.xml and jboss-web.xml are still needed. The change to ear-deployer.xml is not needed.

          Upgrading to 4.0.5 did require code changes because the @EJB annotation moved from javax.annotation.EJB to javax.ejb.EJB.

          Hope this helps someone...