5 Replies Latest reply on Jun 20, 2003 1:37 PM by nash foster

    ClassLoader, MBean problems with redeploy

    Mike Squance Newbie

      Hi,

      I'm getting class cast exceptions because of different class loaders after I do a redeploy of a jar.

      I have an MBean service that is defined by a xyz-service.xml (and accesses the two MBean service class from a jar that is not deployed). This service has a dependency on one of the EJBs from the deployed jar, so when I redeploy the jar, the service gets restarted.

      However, it seems the service is still referencing the class loader used when the jar was deployed the first time (when JBoss was started). I get a class cast exception and when I dump the class loaders of the two versions of the class I find one is the original class loader and one is the new one.

      I've read the following statements from the Admin docs regarding this:

      "This type of error is common when one redeploys an application to which other applications are holding references to classes from the redeployed application. For example, a standalone war accessing an ejb. If you are redeploying an application, all dependent applications must flush their class references. Typically this requires that the dependent applications themselves be redeployed."

      This sounds exactly like my situation. However, as far as I can see, my "dependent" service is being redeployed already. Is there something I can do to flush the class references?

      I'm using JBoss 3.0.6 (and I've tried 3.0.8 and got the same behaviour).

      Thanks for any help.

      Mike.

        • 1. Re: ClassLoader, MBean problems with redeploy
          nash foster Newbie


          > I'm getting class cast exceptions because of
          > different class loaders after I do a redeploy of a
          > jar.

          I'm not sure if my problem is caused by the same issue, but I'm getting ClassCastException thrown when my MBean tries to access an EJB. If I print the class of the object I get from JNDI, it says "$ProxyXXX". Truly annoying.

          > This sounds exactly like my situation. However, as
          > far as I can see, my "dependent" service is being
          > redeployed already. Is there something I can do to
          > flush the class references?

          Yeah, I have this same problem under 3.2.2RC1... I redeploy my MBean, but it doesn't want to work. It boots correctly the first time the server comes up, though. After that, I'm toast...


          -nash

          • 2. Re: ClassLoader, MBean problems with redeploy
            nash foster Newbie

            I haven't solved this yet, but I can now get the MBean to redeploy correctly (sortof). If I just copy the files into the deploy/ directory, it vomits in my lap. But, if I come by after and touch both my jar-file and my sar-file, then it seems to be less angry.

            YMMV...

            • 3. Re: ClassLoader, MBean problems with redeploy
              Darran Lofthouse Master

              Which operating system and JDK versions are you using.

              I have been seeing different class loader problems depending on my JDK version.

              JDK 1.4.0 on Windows 2000 throws NullPointerExceptions and the JVM crashes after redeployment of my service.

              JDK 1.4.1_03 on Windows 2000 still has some class cast issues after redeployment but after a while when the original class loader has been removed everything starts to work Ok.

              • 4. Re: ClassLoader, MBean problems with redeploy
                Mike Squance Newbie

                I'm using JDK 1.4.1_01 on Windows 2000.

                Any idea what causes the original class loader to be removed sometime in the future?

                • 5. Re: ClassLoader, MBean problems with redeploy
                  nash foster Newbie

                  I managed to solve this problem only when one of the other developers here rewrote the build process to assemble everything inside an EAR. Now, everthing builds and deploys correctly and the container is happy.

                  JBoss seems MUCH happier with this configuration than with some of the other approaches (read: wild ASS guesses) I've taken. It especially likes deploying mbeans out of the jboss-app.xml file. When we figured that one out about 25 deployment exceptions magically evaporated, never to return.

                  Here's how we have it setup:

                  META-INF/MANIFEST.MF
                  META-INF/jboss-app.xml
                  META-INF/application.xml
                  myapp-mbeans.sar
                  myapp.jar
                  myapp.war
                  myapp-ds.xml

                  My jboss-app.xml is where we set the mbeans and datasource deployment directives. Here it is:

                  <?xml version="1.0" encoding="ISO-8859-1"?>
                  <!DOCTYPE jboss-app
                  PUBLIC "-//JBoss//DTD J2EE Application 1.3V2//EN"
                  "http://www.jboss.org/j2ee/dtd/jboss-app_3_2.dtd">

                  <jboss-app>

                  myapp-mbeans.sar


                  myapp-ds.xml

                  </jboss-app>

                  And, the application.xml file:

                  <?xml version="1.0" encoding="ISO-8859-1"?>
                  <!DOCTYPE application PUBLIC
                  "-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN"
                  "http://java.sun.com/j2ee/dtds/application_1_2.dtd">


                  <display-name>ScanMeNow</display-name>
                  Scan Me Now application.
                  <!-- this doesn't seem to do anything, but you never know -->
                  myapp-mbeans.sar
                  <!-- EJB Module -->

                  myapp.jar



                  <web-uri>myapp.war</web-uri>
                  <context-root>/foo</context-root>