5 Replies Latest reply on Dec 5, 2002 9:05 AM by aradka

    Even More  Challenging Class Loading problem



      I have the same problem as the one yusdi described in his posting from Oct 9th, although in a different context.

      I have an EAR containing EJBs and a WAR, and also two MBeans that access some of the EJBs.

      I had a depends problem but I managed to find a solution for it in the newsgroups here - just had to add some depends tags to the mbeans.

      Now the problem that is left is on re-deployment of the EAR containing the EJBs. When the MBeans try to access the EJBeans they get ClassCast or Class not compatible exceptions. This is despite the depends tags - JBoss does stop the MBeans & start them again but it does not re-deploy them.

      The solutions to yusdi's problem does not apply here because I am not using a classloader directly - I am just importing the classes & directly accessing them from my code (statically).

      Most probably I could package the MBeans (currently .sar archives) into the EAR to force them being redeployed, or manually re-deploy them through the JMX interface to fix that.

      I am not very interested in those solutions however, becaue they would make it too complex to redeploy the EAR -

      * If I package the MBeans into the EAR, the file would grow too large & upload to our production server would take too long.
      * If I have to manually redeploy the MBeans I lose the one-step quick update process that I am enjoying right now.

      So I was wondering if there is some solution to the problem - it persists in both JBoss 3.0.3 and 3.2.0beta. Would it be possible to force the MBeans to be redeployed on redeployment of the EAR? Or is it possible to force the java runtime to use the proper classloader?


        • 1. Re: Even More  Challenging Class Loading problem

          P.S. Actually herer are the two errors I get:


          java.lang.LinkageError: loader constraints violated when linking admintool/ejb/stateless/AccessManager class
          at rtb.server.RealTimeBidder.authenticateAdministrator(RealTimeBidder.java:83)

          Here is the code:

          package rtb.server;


          import admintool.ejb.stateless.*; // Package containing AccessManagerHome


          // Line 83
          AccessManager am = ((AccessManagerHome) EJBHelper.getHome("AccessManagerHome", AccessManagerHome.class)).create();



          at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:291)
          at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:132)
          at auctionengine.auctionlayer.EJBHelper.getAuctionFromEJB(EJBHelper.java:192)

          And the code:

          package auctionengine.auctionlayer;


          import admintool.ejb.stateless.OnlineAuctionsManagerHome;


          // Line 191
          Object ref = jndiContext.lookup("OnlineAuctionsManagerHome");
          // Line 192
          OnlineAuctionsManagerHome home = (OnlineAuctionsManagerHome) PortableRemoteObject.narrow(ref, admintool.ejb.stateless.OnlineAuctionsManagerHome.class);


          • 2. Re: Even More  Challenging Class Loading problem

            Are you using java 1.4?
            Does it work if you remove the narrow operation
            and do a straight cast?

            Object ref = jndiContext.lookup("OnlineAuctionsManagerHome");
            OnlineAuctionsManagerHome home = (OnlineAuctionsManagerHome) ref;


            • 3. Re: Even More  Challenging Class Loading problem

              I am using Java 1.3.1_05, but I tried 1.4.1 - same result.
              When i remove the narrow operation I get a classcast exception:

              java.lang.ClassCastException: $Proxy175
              at auctionengine.auctionlayer.EJBHelper.getAuctionFromEJB(EJBHelper.java:192)


              I did some debugging & found out that Java uses correctly the UniformClassLoader (or whatever jboss's classloader is called) when it does its internal classloading.

              However the problem is that the classes are not "unloaded" on redeploy of the EAR. I tried clearing all references I have & making an explicit System.gc() call in my destroyService() method, hoping that this would unlink the EJB classes - no luck, it did not help.


              • 4. Re: Even More  Challenging Class Loading problem

                If that is true, it is a bug.

                I had heard of problems with narrow on 1.4 because
                of the JVM caching classes in the RMI layer, but
                I'm pretty sure this was fixed.

                Can you create a simple test that reproduces the
                problem and post it as a bug at


                • 5. Re: Even More  Challenging Class Loading problem

                  Was this ever fixed. I couldn't find anything matching it in the big list?

                  I am having a similar (yet slightly different) problem. I didn't want to post all the details in a new thread, if this has been fixed in a later release (I am using jboss-3.0.3_tomcat-4.1.12).