Significado de java.lang.ClassCastException: someClass incompatible con someClass

Question

Experimenté excepciones ocasionales en la aplicación XPages:

java.lang.ClassCastException: someClass incompatible with someClass.

Ambas clases mencionadas son iguales, es una clase usada como bean de sesión.No pude buscar en Google nada que cubra mi problema.La explicación habitual de esto fue un cambio en los elementos de diseño, no mi caso.

La aplicación XPage se vuelve inutilizable (las páginas que usan el bean de sesión someClass) desde ese momento, hasta que se reinicia la tarea http o se vuelve a guardar faces-config.xml.

En algunos casos, esto está relacionado con otra excepción:

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

¿Qué hay detrás de este comportamiento?

Answer 1

Philippe Riand lo explicó por correo electrónico:

Esta conversión de clase ocurre porque la misma clase ha sido cargada dos veces por 2 cargadores de clases diferentes. Por lo tanto, desde el punto de vista de Java, son diferentes y la transmisión falla.

Ahora, cada aplicación de XPages tiene su propio cargador de clases. Pero este cargador de clases se descarta cada vez que ocurre un cambio de diseño en la aplicación, a través de Domino Designer, por ejemplo. Esto es necesario ya que un cambio en una XPages genera una nueva clase Java que luego debe cargarse en lugar de la anterior. Cuando esto sucede, el cargador de clases se descarta y se crea uno nuevo. Luego, todas las clases relacionadas con la aplicación se recargan, según sean necesarias, aunque no hayan cambiado. Este es un comportamiento común implementado por los servidores J2EE. Dicho esto, si su código está almacenando en caché un objeto en un alcance que no se descarta cuando ocurre un cambio de diseño, es probable que esto suceda. Por ejemplo, applicationScope y sessionScope actualmente no se descartan cuando se produce un cambio de diseño, lo que podría provocar este problema. Esta fue una elección de diseño, ya que descartar los osciloscopios a veces proporciona una mala experiencia para el desarrollador, pero con este inconveniente.

Finalmente, guardar faces-config.xml funciona como una solución. Cuando se guarda este archivo, todo el módulo se descarta de la memoria, incluidos los ámbitos. Esto explica por qué funciona. Hacer un cambio en su clase Java personalizada debería volver a cargar el módulo y eliminar el problema.

Por lo que parece que poner beans (incluso indirectamente) en sessionScope o applicationScope es la causa.

Answer 2

Si se carga el mismo archivo de clase en diferentes cargadores de clases, las dos clases Java resultantes no son la misma clase;no se le permitirá pasar instancias de una a funciones que esperan la otra.Generalmente, si está viendo este tipo de problema, es porque tiene varios cargadores de clases secundarios que pueden acceder a un archivo jar que no es visible para su cargador de clases principal común.Es posible que deba mover el contenedor que contiene "alguna clase" a un directorio de biblioteca común en lugar de (por ejemplo) un directorio de aplicaciones web específico.

Answer 3

Solo pongo mi experiencia aquí.

Estaba ejecutando mi aplicación en un entorno CAT con varias JVM cuando encontré este problema.Debido a que la misma compilación se estaba ejecutando con éxito para mí en el entorno ITG, reinicié ambas JVM en CAT y se resolvió el error.No estoy seguro de qué lo estaba causando.

Answer 4

¡Limpiar el proyecto también hace que esto funcione!