実装するだけSerializable
あなたがNotSerializableException次のようなものを得ているなら、
java.io.NotSerializableException: bean.ProjectAreaBean
その場合、それは単に、例外メッセージ（あなたの場合）で完全修飾名で識別されるクラスが、背後のコードによって予期されている間bean.ProjectAreaBean、インターフェースを実装しないことを意味します。Serializable修正は比較的簡単で、クラスにSerializableインターフェースを実装させるだけです。
package bean;
import java.io.Serializable;
public class ProjectAreaBean implements Serializable {
private static final long serialVersionUID = 1L;
// ...
}
このserialVersionUIDフィールドは必須ではありませんが、クラスの異なるバージョンとそのインスタンスのシリアル化された表現の間のバイナリ互換性を維持するため、強くお勧めします。serialVersionUIDしたがって、後で新しいシリアル化可能なフィールドをクラスに追加するときは、古いバージョンのクラスのインスタンスの逆シリアル化中の問題を防ぐために、フィールドを変更する必要があります（通常は1ずつ増やすだけで十分です）。serialVersionUIDEclipseなどのIDEには、基本的にすべてのフィールドに基づいて計算されたハッシュである値を（再）生成するオプションもあります。
参照：
シリアル化できないフィールドをマークするtransient
Serializableクラスに、絶対に作成できない別のクラスのインスタンスを参照するフィールド/プロパティが含まれている場合（Serializable通常、これらは、などのリソースを表しInputStreamますConnection）、マークを付ける必要がありますtransient。このように、クラスのシリアル化中にスキップされます。
private transient SomeObject thisWillNotBeSerialized;
デシリアライズ後、このフィールドは常に。になることを理解する必要がありますnull。クラスのコンストラクターと初期化ブロックは、逆シリアル化中に呼び出されないことに注意してください。シリアル化と逆シリアル化をよりきめ細かく制御したい場合は、readObject()andwriteObject()メソッドをオーバーライドします。以下のリンクで具体的な例を見つけることができます。
なぜシリアル化するのですか？
シリアル化について心配する必要がある理由についてSerializableは、TomcatなどのほとんどのJavaサーブレットコンテナでは、クラスのインスタンスがの属性として格納されるたびに、クラスを実装する必要があるためHttpSessionです。これはHttpSession、サーブレットコンテナをシャットダウン/再起動する必要がある場合、またはセッションを同期する必要があるサーバーのクラスタに配置する場合に、ローカルディスクファイルシステムに保存するか、ネットワーク経由で転送する必要があるためです。
Javaオブジェクトをローカルディスクファイルシステムに保存したり、ネットワーク経由で転送したりするには、最初にバイトストリーム（基本的にはabyte[]またはInputStream）に変換する必要があります。これは、オブジェクトの背後にあるクラスが実装されている場合にのみ可能です。Serializable。Serializableインターフェイス自体は実際には何もしません。単なるマーカーインターフェイスです。背後にあるコードは、instanceof Serializableそれに応じて動作するようにセッション属性をチェックするだけです。
参照：