mettre en œuvre Serializable

si vous recevez un NotSerializableException comme suit,

java.io.NotSerializableException: bean.ProjectAreaBean

alors cela signifie simplement que la classe identifiée par le nom entièrement qualifié dans le message d'exception (qui est bean.ProjectAreaBean dans votre cas) ne met pas en œuvre l'interface Serializable alors qu'il est prévu par le code derrière. La fixation est relativement simple, il suffit de laisser la classe implémente l'interface Serializable .

package bean;

import java.io.Serializable;

public class ProjectAreaBean implements Serializable {
    private static final long serialVersionUID = 1L;

    // ...
}

le champ serialVersionUID n'est pas nécessaire, mais fortement recommandé car il maintient la compatibilité binaire entre les différentes versions de la classe et les représentations sérialisées de ses instances. Donc quand vous ajoutez plus tard un nouveau champ serialisable à la classe, alors vous devez changer le champ serialVersionUID (généralement juste incrémenter de 1 est suffisant) pour prévenir les problèmes pendant la désérialisation d'une instance d'une ancienne version de la classe. IDEs comme Eclipse offrent également une option pour (re)générer la valeur serialVersionUID qui est essentiellement un hachage calculé sur la base de tous les champs.

voir aussi:

• JSF managed bean provoquant java.io.NotSerializableException cours de déploiement Tomcat
• Injection non sérialisable application étendue bean géré propriété de session sérialisable scoped bean dans un cluster
• Qu'est-ce qu'une versionérielle et pourquoi devrais-je l'utiliser?

---

Marque unserializable champs transient

si votre classe Serializable contient à son tour un champ / propriété faisant référence à une instance d'une autre classe qui ne peut absolument pas être faite Serializable , alors vous devez le marquer transient . De cette façon, il sera ignoré lors de la sérialisation de la classe.

private transient SomeObject thisWillNotBeSerialized;

vous devez comprendre qu'après la desérialisation ce champ deviendra toujours null . Notez que les blocs de construction et d'initialisation de la classe sont et non invoqués lors de la desérialisation. Si vous souhaitez avoir un contrôle plus fin sur la sérialisation et la desérialisation, alors outrepassez les méthodes readObject() et writeObject() . Vous vous trouverez des exemples concrets dans les liens ci-dessous:

• empêcher la sérialisation de l'arbre des composants pour certaines parties de la demande
• Comment faire des Cookies persistants avec un DefaultHttpClient sur Android?

---

pourquoi la sérialisation?

comme le pourquoi vous devez vous soucier de serialization, c'est parce que la plupart des conteneurs Java servlet comme Tomcat nécessitent des classes pour implémenter Serializable chaque fois que les instances de ces classes sont stockées comme un attribut de la HttpSession . Cela est dû au fait que le HttpSession peut avoir besoin d'être sauvegardé sur le système de fichiers Disque local ou même transféré sur le réseau lorsque le conteneur servlet doit être arrêté/redémarré ou est placé dans un groupe de serveurs où la session doit être synchronisée.

pour pouvoir sauvegarder des objets Java sur le système de fichiers Disque local ou les transférer sur le réseau, ils doivent d'abord être convertis en flux octet (essentiellement: un byte[] ou un InputStream ) et cela n'est possible que si la classe derrière l'objet implémente Serializable . L'interface Serializable elle-même ne fait pas grand chose, c'est simplement une interface marqueur .

voir aussi:

• java.io.Serializable javadoc
• Java Sérialisation D'Un Objet Spécification
• Tutoriels Java - Catégories Essentielles De Base I/O - Objet Ruisseaux

vous devez rendre bean.ProjectAreaBean sérialisable.