Originally posted by Eugene Kononov:
Has your class changed recently (new methods/data member, changed signatures)? Do you explicitely declare the field named serialVersionUID? Do you use a default or a custom implementation of the Serializable?
The class hasn't changed recently. We are not explicitly declaring the serialVersionUID. We are using the default implementation of Serializable. I think I (almost) figured out the problem though. We have our app deployed on WLS 7. I have one jar file containing some ejbs and a war file containging my web app which uses these EJBs. Inside the war file, however, I have all the classes from the EJB module under the WEB-INF/ classes (this is the way the build was set up when I got here recently). This appears to be a bad idea according to what I am reading in the WL documentation due to the fact that they are loaded by sibling class loaders which can apparently lead to these types of exceptions (I am still not sure exactly why though). Here is the documentation from BEA that makes me think this is the problem:
"Although you could deploy the WAR and JAR files separately, deploying them together in an EAR file produces a classloader arrangement that allows the
servlets and JSPs to find the EJB classes. If you deploy the WAR and JAR files separately, WebLogic Server creates sibling classloaders for them. This means that you must include the EJB home and remote interfaces in the WAR file, and WebLogic Server must use the RMI stub and skeleton classes for EJB calls, just as it does when EJB clients and implementation classes are in different JVMs."
"RMI call optimization and call by reference can only be used when the caller and callee are within the same application. As usual, this is related to classloaders. Since applications have their own classloader hierarchy, any application class has a definition in both classloaders and receives a ClassCastException error if you try to assign between applications. To work around this, WebLogic Server uses call by value between applications, even if they are within the same JVM."
"Applications usually have shared utility classes. If you create or acquire utility classes that you will use in more than one application, you must package them with each application as separate JAR files. The JAR files should be self contained and not have any references to the classes in the EJB or Web components. Common types of shared utility classes are data transfer objects or JavaBeans, which are passed between the Web tier and EJB tier."
If someone can explain to me exactly why having these EJB classes in both modules causes the InvalidClassException and the mismatched serialVersionUIDs even though both of the class files are identical - that would be very informative.
)