2 Replies Latest reply on Apr 27, 2005 1:22 PM by Erik Hansen

    ClassCastException and redeploy--could serialization with Ob

    squeak Newbie

      I have an EAR file that has EJB's in it, along with a WAR file.

      My application makes uses of Apache's OJB tool, which is linked into my EAR file inside the Application.xml.

      Now, when I initially deploy my application, everything works fine. However, when I redeploy, I get the dreaded ClassCastException. My entire application is in the same EAR File, so I don't think I have the standard EJB ClassCastException issue. The failure happens inside of OJB's configuration mechnism, and how it handles Metadata for JdbcConnections

      I have tracked it down inside of OJB's code to a point where they return a collection of JdbcConnections, but only after it has been serialized (cloned) using commons-lang's SerializationUtils.clone().

      To verify this, I changed the code to say which classloader the JdbcConnection was coming from before and after the clone via serialization.

      Here is the ouput of that:

      17:02:09,592 INFO [STDOUT] ClassLoader for org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
      Serialization: org.jboss.mx.loading.UnifiedClassLoader3@157566d{
      url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
      ,addedOrder=37}
      17:02:18,811 INFO [STDOUT] ClassLoader for org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
      Serialization: org.jboss.mx.loading.UnifiedClassLoader3@157566d{
      url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
      ,addedOrder=37}
      


      Both the original and clone are loaded from the same classloader, as we would expect. But after redeploying the EAR file, they are in different loaders (OJB later on tries to cast the cloned into it's version of the class, causing the exception)

      17:03:04,780 INFO [STDOUT] ClassLoader for org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
      Serialization: org.jboss.mx.loading.UnifiedClassLoader3@f00b97{
      url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear
      ,addedOrder=38}
      17:03:11,280 INFO [STDOUT] ClassLoader for org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
      Serialization: org.jboss.mx.loading.UnifiedClassLoader3@157566d{
      url=null ,addedOrder=37}
      


      The classloaders are different, and the ClassLoader of the serialized version is the same classloader from before the redeployment.

      Looking into how SerializationUtils.clone() works, all it does is a standard serizalization/deseralize using ObjectInputStream to copy the Object.

      Looking at the code for ObjectInputStream.readObject, it does a Class.forName() to create the new object. Could that be the cause of the problem? I thought you shouldn't be doing Class.forName() with the UnifiedClassLoader because of issues like this. Is that accurate? Could what I describe, and the output from the classloaders be the same? (I am thinking yes since the url for the serialized copy after redeployment is null).

      Thanks in advance!


        • 1. Re: ClassCastException and redeploy--could serialization wit
          Erik Hansen Newbie

          I'm seeing this same problem and I was wondering the same thing.

          I have a scheduler mbean (in a SAR) that invokes a method in a class which in turn looks up a stateless session bean and executes some methods. The first time I run it after deployment, everything works as expected. If I redeploy, I get ClassCastExceptions when I cast the LocalHome interface returned from my naming context lookup to the corresponding LocalHome interface.

          Most of the other references to this problem that I've found suggest packaging the SAR inside the EAR so that they use the same classloader. This is exactly what I'm doing -- but I still get the ClassCastExceptions.

          This was working, but I recently switched to secured EJBs and login using the LoginInitialContextFactory to get the Naming context for the EJBs -- instead of just using the name lookup methods created in the XxxEjbUtil classes generated via XDoclet. Is there some problem with the way the LoginInitialContextFactory works that's causing this? Looking at the source, it doesn't appear so.

          If I'm packaging the SAR inside the EAR file (that contains the JAR with the EJBs) why am I still getting ClassCastExceptions after redeployment? I should be using the same classloader...

          Jboss 3.2.3/Java 1.4.2

          • 2. Re: ClassCastException and redeploy--could serialization wit
            Erik Hansen Newbie

            Well, I'm not seeing this in JBoss 3.2.7, so I guess whatever it was has been taken care of.