Meaning of java.lang.ClassCastException: someClass incompatible with someClass

Question

I was experiencing occasional exceptions in XPages application:

java.lang.ClassCastException: someClass incompatible with someClass.

Both mentioned classes are the same, it is class used as session bean. I was not able to google anything covering my problem. Usual explanation for this was change in design elements, not my case.

The XPage application become unusable (pages using session bean someClass) since that moment, until restart of http task, or resave of faces-config.xml.

In some cases this is related to other exception:

com.ibm.jscript.InterpretException: Script interpreter error, line=x, col=y: 
Java method 'method(signature containg someClass)'
on java class 'someOtherClass' not found

What is behind this behavior?

Answer 1

Philippe Riand explaned this by email:

This class cast happens because the same class had been loaded twice by 2 different class loaders. Thus, from a Java standpoint, they are different and the cast fails.

Now, each XPages application is having its own classloader. But this class loader is discarded each time a design change happens to the application, through Domino Designer for example. This is required as a change to an XPages generates a new Java class that should then be loaded instead of the previous one. When this happens, the classloader is discarded and a new is created. Then all the application related classes are reloaded, as they are needed, even though they didn't change.This is a common behavior implemented by J2EE servers. That said, if your code is caching an object in a scope that is not discarded when a design change occurs, then this is likely to happen. For example, the applicationScope & sessionScope are currently not discarded when a design change happens, which might lead to this problem. This was a design choice as discarding the scopes sometimes provides a bad developer experience, but with this drawback.

Finally, saving faces-config.xml works as a workaround. When this file is saved, then the entire module is discarded from memory, including the scopes, This explains why it works. Making a change to your custom Java class should reload the module and remove the issue.

So it seems putting beans (even indirectly) into sessionScope or applicationScope is the cause.

Answer 2

If the same class file is loaded in different class loaders, the two resulting Java classes are not the same class; you wouldn't be allowed to pass instances of one to functions expecting the other. Generally, if you're seeing this kind of problem, it's because you've got multiple child classloaders that can access a jar file that's not visible to their common parent classloader. You may need to move the jar containing "someclass" to a common library directory instead of (for example) a specific webapp directory.

Answer 3

Just putting my experience over here.

I was running my app on CAT environment with multiple JVMs when I came across this issue. Because the same build was running successfully for me on ITG environment, I restarted both the JVMs on CAT and the error was resolved. Not exactly sure what was causing it.

Answer 4

Cleaning the project also make this works!