Rückwärts Kompatibel in xstream

Question

Ich benutze nette kleine Stück Xstream, um Serialisierung durchzuführen.

Ich habe die folgende Klasse:

// version 0 
class A { 
} 

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

Um für mich Version 0 xml-Datei zu lesen Version 1 Klasse A zu konstruieren, muss ich die folgende Methode in Version 1 Klasse A hinzuzufügen:

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

Das funktioniert soweit.

Jetzt wird die Situation umgekehrt.

ich die folgende Klasse:

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

// version 1 
class A { 
} 

Wie kann ich in der Lage 0, Lesen von XML-Dateiversion machen Klasse 1 A-Version zu konstruieren?

Hier ist die Ausnahme, die Sie erhalten werden, wenn Sie versuchen, dies zu tun:

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

Derzeit habe ich rückwärtskompatibel die folgende Strategie:

// 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

Sie einen benutzerdefinierten Konverter für Klasse-A-Register könnte, die Sie die Kontrolle über das msrshalling und unmarshalling gibt. Es ist eine ziemlich schwergewichtige Lösung und macht XStream ziemlich unattraktiv.

Aufgrund von Fällen wie diesem tendiere ich dazu, XStream für alles andere als sehr triviale Situationen zu vermeiden, und niemals für Situationen, in denen XML über die Lebensdauer der laufenden Anwendung hinaus bestehen könnte. Es ist einfach zu zerbrechlich (und fehlerhaft). Ein robusteres Marshalling-Framework wäre freiwillig, auch wenn sie mehr Konfigurationsaufwand benötigen.