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.