Bedeutung von java.lang.ClassCastException: someClass nicht kompatibel mit someClass

Question

In der XPages-Anwendung traten gelegentlich Ausnahmen auf:

java.lang.ClassCastException: someClass incompatible with someClass.

Beide genannten Klassen sind gleich, es handelt sich um eine Klasse, die als Session Bean verwendet wird.Ich konnte nichts googeln, was mein Problem abdeckte.Die übliche Erklärung dafür war die Änderung der Designelemente, nicht mein Fall.

Die XPage-Anwendung wird seit diesem Moment unbrauchbar (Seiten mit Session Bean someClass), bis die http-Task neu gestartet oder die Datei gesicht-config.xml erneut gespeichert wird.

In einigen Fällen hängt dies mit einer anderen Ausnahme zusammen:

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

Was steckt hinter diesem Verhalten?

Answer 1

Philippe Riand erklärte dies per E-Mail:

Diese Klassenbesetzung erfolgt, weil dieselbe Klasse zweimal von zwei verschiedenen Klassenladern geladen wurde. Aus Java-Sicht sind sie daher unterschiedlich und die Umwandlung schlägt fehl.

Jetzt hat jede XPages-Anwendung einen eigenen Klassenladeprogramm. Dieser Klassenladeprogramm wird jedoch jedes Mal verworfen, wenn eine Designänderung an der Anwendung vorgenommen wird, z. B. über Domino Designer. Dies ist erforderlich, da durch eine Änderung an XPages eine neue Java-Klasse generiert wird, die dann anstelle der vorherigen geladen werden sollte. In diesem Fall wird der Klassenladeprogramm verworfen und ein neues erstellt. Anschließend werden alle anwendungsbezogenen Klassen nach Bedarf neu geladen, obwohl sie sich nicht geändert haben. Dies ist ein häufiges Verhalten, das von J2EE-Servern implementiert wird. Wenn Ihr Code jedoch ein Objekt in einem Bereich zwischenspeichert, der nicht verworfen wird, wenn eine Entwurfsänderung auftritt, ist dies wahrscheinlich. Beispielsweise werden applicationScope und sessionScope derzeit nicht verworfen, wenn eine Entwurfsänderung auftritt, die zu diesem Problem führen kann. Dies war eine Designentscheidung, da das Verwerfen der Bereiche manchmal eine schlechte Entwicklererfahrung bietet, jedoch mit diesem Nachteil.

Schließlich funktioniert das Speichern von face-config.xml als Problemumgehung. Wenn diese Datei gespeichert wird, wird das gesamte Modul einschließlich der Bereiche aus dem Speicher verworfen. Dies erklärt, warum es funktioniert. Wenn Sie eine Änderung an Ihrer benutzerdefinierten Java-Klasse vornehmen, sollte das Modul neu geladen und das Problem behoben werden.

Es scheint also, dass das Einfügen von Beans (auch indirekt) in sessionScope oder applicationScope die Ursache ist.

Answer 2

Wenn dieselbe Klassendatei in verschiedenen Klassenladeprogrammen geladen wird, sind die beiden resultierenden Java-Klassen nicht dieselbe Klasse.Sie dürfen keine Instanzen von einer an Funktionen übergeben, die die andere erwarten.Wenn Sie diese Art von Problem sehen, liegt dies im Allgemeinen daran, dass Sie mehrere untergeordnete Klassenladeprogramme haben, die auf eine JAR-Datei zugreifen können, die für ihren gemeinsamen übergeordneten Klassenladeprogramm nicht sichtbar ist.Möglicherweise müssen Sie das JAR mit "someclass" in ein allgemeines Bibliotheksverzeichnis verschieben, anstatt (zum Beispiel) in ein bestimmtes Webanwendungsverzeichnis.

Answer 3

Ich stelle nur meine Erfahrungen hierher.

Ich habe meine App in einer CAT-Umgebung mit mehreren JVMs ausgeführt, als ich auf dieses Problem gestoßen bin.Da derselbe Build für mich in der ITG-Umgebung erfolgreich ausgeführt wurde, habe ich beide JVMs in CAT neu gestartet und der Fehler wurde behoben.Ich bin mir nicht ganz sicher, was es verursacht hat.

Answer 4

Wenn Sie das Projekt bereinigen, funktioniert dies auch!