答えのないもの
選択したクラスのシリアル化を無効にするアプローチには注意してください。ローカルまたは一部の制限された開発環境で実行する場合、アプリケーションを「クラスター化」する必要はなく、レプリケートされたセッションまたはステートフル エンティティを必要としない場合があります。ただし、テストまたは本番環境にデプロイすると、クラスター化できます。シリアライゼーションを妨げていると、壊れてしまいます。
したがって、アクションの最善の原因は、強制的に防止するのではなく、クラスの「シリアライズ可能性」を確保することです。
連載OFF回答
シリアル化を無効にすることを主張する場合は、<distributable/>
から削除することweb.xml
でうまくいくはずです。
シリアライズ不可能な回答のシリアライズ
一部のクラスをシリアライズ可能にしようとすると、特定のクラス メンバーの型が単純にシリアライズ不可能であり、シリアライズする同様のものと型を入れ替えることができない場合があります。次に、適用可能な場合は、次のトリックを使用します。
public class ClassForcedToBeSerializable implements Serializable {
transient private FileWriter writer; //FileWriter is not serializable!!!
private final File file;
public ClassForcedToBeSerializable(File file) throws IOException {
this.file = file;
this.writer = new FileWriter(file);
}
//FLESH AND BONES HERE
private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
if (writer == null) {
this.writer = new FileWriter(file);
}
}
}
ご覧のとおり、クラスにはFileWriter
タイプのフィールドが含まれています。オブジェクトをマークすることで、オブジェクト -> バイトのシリアル化を保証しましたtransient
。ただし、リモート JVM では、このクラスがバイトから戻されると、FileWriter
フィールド フィールドは になりますnull
。デシリアライゼーション中に再作成することで、この問題を回避します (readObject()
方法を参照)。
この例が機能するのは、フィールドが正常に再作成されるのにFile
十分な状態を保持しているからです。FileWriter