Backward Compatible dans xstream

Question

J'utilise un petit morceau sympa de xstream pour effectuer la sérialisation.

J'ai la classe suivante:

// version 0 
class A { 
} 

// version 1 
class A { 
    Object o = new Object(); 
} 

Pour moi de lire la version 0 fichier xml pour construire la version 1 classe A, je vais devoir ajouter la méthode suivante dans la version 1 classe A:

class A { 
    private Object readResolve() 
    { 
     /* For backward compatible */ 
     if (o == null) { o = new Object(); } 
    } 
    Object o = new Object(); 
} 

Cela fonctionne très bien jusqu'à présent.

Maintenant, la situation est inversée.

J'ai la classe suivante:

// version 0 
class A { 
    Object o = new Object(); 
} 

// version 1 
class A { 
} 

Comment puis-je en mesure de faire la lecture de la version du fichier xml 0, pour construire la classe A version 1?

est ici l'exception que vous allez obtenir, si vous essayez de le faire:

run: 
com.thoughtworks.xstream.converters.ConversionException: a : a 
---- Debugging information ---- 
message    : a : a 
cause-exception  : com.thoughtworks.xstream.mapper.CannotResolveClassException 
cause-message  : a : a 
class    : javaapplication15.Main$A 
required-type  : javaapplication15.Main$A 
path    : /javaapplication15.Main$A/a 
line number   : 2 
------------------------------- 
null 
BUILD SUCCESSFUL (total time: 2 seconds) 

Answer 1

Actuellement, je rencontre rétrocompatible en utilisant la stratégie suivante:

// version 0 
class A { 
    Object o = new Object(); 
} 

// version 1 
class A { 
    // This will ensure o will not be be read, or be written into file. 
    // transient keyword which prevent read, will only work well for xstream 1.3.1 
    transient Object o = new Object(); 
} 

// version 2. Slowly phase out Object o, after class A had been deployed for quite sometime. 
class A { 
} 

Answer 2

Vous pouvez enregistrer un convertisseur de mesure pour la classe A, qui vous permet de contrôler la msrshalling et unmarshalling. C'est une solution assez lourde, et rend XStream moins attrayant. C'est à cause de ces cas que j'ai tendance à éviter XStream pour tout ce qui n'est pas très trivial, et jamais pour les situations où le XML pourrait être conservé au-delà de la durée de vie de l'application en cours d'exécution. C'est juste trop fragile (et buggé). Un cadre de marshaling plus robuste serait par choix, même s'ils prennent plus d'effort initial pour configurer.