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: [EMAIL PROTECTED] | 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: [EMAIL PROTECTED] | 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: [EMAIL PROTECTED] | 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: [EMAIL PROTECTED] | 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! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845073#3845073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3845073 ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
