java.lang.ClassCastExceptionの意味：someClassはsomeClassと互換性がありません

Question

XPagesアプリケーションで時折例外が発生していました： ジェネラコディセタグプレ

上記のクラスはどちらも同じで、セッションBeanとして使用されるクラスです。私は自分の問題をカバーするものをグーグルで検索することができませんでした。これについての通常の説明は、私の場合ではなく、設計要素の変更でした。

XPageアプリケーションは、その瞬間からhttpタスクを再起動するか、faces-config.xmlを再保存するまで、使用できなくなります（セッションBean someClassを使用するページ）。

場合によっては、これは他の例外に関連しています： ジェネラコディセタグプレ

この動作の背後にあるものは何ですか？

Answer 1

Philippe Riandがこれをメールで説明しました：

このクラスキャストは、同じクラスが2つの異なるクラスローダーによって2回ロードされたために発生します。したがって、Javaの観点からは、それらは異なり、キャストは失敗します。

現在、各XPagesアプリケーションには独自のクラスローダーがあります。ただし、このクラスローダーは、Domino Designerなどを介して、アプリケーションに設計変更が発生するたびに破棄されます。 XPagesを変更すると、新しいJavaクラスが生成され、前のクラスの代わりにロードする必要があるため、これが必要です。これが発生すると、クラスローダーは破棄され、新しいクラスローダーが作成されます。次に、アプリケーションに関連するすべてのクラスが、変更されていなくても、必要に応じて再ロードされます。これは、J2EEサーバーによって実装される一般的な動作です。 とはいえ、設計変更が発生したときに破棄されない スコープ内のオブジェクトをコードがキャッシュしている場合、これが発生する可能性があります。たとえば、applicationScopeとsessionScopeは現在、設計変更が発生しても破棄されないため、この問題が発生する可能性があります。スコープを破棄すると開発者のエクスペリエンスが低下することがあるため、これは設計上の選択でしたが、この欠点があります。

最後に、faces-config.xmlの保存は回避策として機能します。このファイルが保存されると、スコープを含むモジュール全体がメモリから破棄されます。これが、このファイルが機能する理由を説明しています。カスタムJavaクラスに変更を加えると、モジュールがリロードされ、問題が解消されます。

したがって、beanを（間接的にでも）sessionScopeまたはapplicationScopeに配置することが原因のようです。

Answer 2

同じクラスファイルが異なるクラスローダーにロードされる場合、結果として得られる2つのJavaクラスは同じクラスではありません。 一方のインスタンスをもう一方を期待する関数に渡すことは許可されません。一般に、この種の問題が発生している場合は、共通の親クラスローダーには表示されないjarファイルにアクセスできる子クラスローダーが複数あることが原因です。「someclass」を含むjarを、（たとえば）特定のwebappディレクトリではなく、共通のライブラリディレクトリに移動する必要がある場合があります。

Answer 3

私の経験をここに置くだけです。

この問題が発生したとき、複数のJVMを備えたCAT環境でアプリを実行していました。同じビルドがITG環境で正常に実行されていたため、CATで両方のJVMを再起動すると、エラーが解決されました。何が原因か正確にはわかりません。

Answer 4

プロジェクトをクリーンアップすると、これも機能します！