In XStream gibt es eine bessere Möglichkeit, ListObject in JSON und Java marshall / unmarshall

8

Ich benutze XStream und JETTISONs Stax JSON-Serializer, um Nachrichten an JSON-Javascripts-Clients zu senden / von diesen zu empfangen und Java-Webanwendungen.

Ich möchte in der Lage sein, eine Liste von Objekten zu erstellen, die an den Server gesendet und ordnungsgemäß in Java gemarshallt werden, aber das Format, in dem XStream und JSON es erwarten, ist sehr unintuitiv und benötigt unsere Javascript-Bibliotheken, um durch die Hoops zu springen.

[BEARBEITEN Aktualisiere Probleme mit der GSON Bibliothek] Ich habe versucht, die GSON-Bibliothek zu verwenden, aber sie kann keine konkreten Objekte deserialisieren, wenn ich nur generische Super-Klassen erwarte ( XStream und Jettison verarbeiten dies, weil Typinformationen in die Serialisierung übernommen werden.

In der GSON-FAQ wird die Einschränkung der Sammlung angegeben :

  

Sammlungsbeschränkungen

     

Kann eine Sammlung von beliebigen Objekten serialisieren, aber nicht aus ihr deserialisieren

     

Da der Benutzer den Typ des resultierenden Objekts nicht angeben kann

     

Beim Deserialisieren muss die Sammlung einen bestimmten generischen Typ aufweisen

Vielleicht verwende ich schlechte Java-Praktiken, aber wie sollte ich ein JSON-zu-Java-Messaging-Framework aufbauen, das verschiedene konkrete Message-Objekte im JSON-Format sendet / empfängt?

Dies schlägt beispielsweise fehl:

%Vor%

Hier ist ein Beispiel, ich möchte eine Liste von 3 Message-Objekten senden, 2 sind vom selben Typ und der 3. ist ein anderer Typ.

%Vor%

Intuitiv erwarte ich, dass der XStream-JSON serialisiert wird (und in der Lage ist, korrekt zu deserialisieren) von folgendem Format:

%Vor%

Stattdessen erstellt XStream eine einzelne Elementliste mit Feldern, die die Klassennamen und verschachtelten Arrays von Objekten desselben Typs genannt werden.

%Vor%

Das Problem kann durch die Verwendung des XStream-XML CollectionConverter verursacht werden.

Hat jemand einen Vorschlag für eine gute JSON-Java-Objektserialisierung, mit der Sie beliebige Java-Objekte lesen / schreiben können? Ich schaute auf den Jackson Java JSON-Prozessor , aber beim Einlesen von Objekten aus einem Stream mussten Sie angeben, um welchen Objekttyp es sich handelte XStream, wo es in jedem Objekt gelesen wird (weil der serialisierte XStream-JSON Informationen zum Klassennamen enthält).

    
Dougnukem 07.05.2009, 20:14
quelle

3 Antworten

6

Ich stimme mit anderen Postern darin überein, dass XStream nicht gut passt - es ist ein OXM (Object / Xml Mapper) und JSON wird als sekundäres Ausgabeformat unter Verwendung des XML-Verarbeitungspfades behandelt. Dies ist der Grund, warum eine "Konvention" (wie man ein hierarchisches XML-Modell in ein Objekt-Graph-Modell von json und umgekehrt umwandelt) benötigt wird; und Ihre Wahl läuft darauf hinaus, das zu verwenden, was die suboptimalen Entscheidungen am wenigsten beeinträchtigt. Das funktioniert, wenn XML Ihr primäres Datenformat ist und Sie nur eine rudimentäre JSON-Unterstützung benötigen.

Um eine gute JSON-Unterstützung zu erhalten, würde ich eine JSON-Verarbeitungsbibliothek in Erwägung ziehen, die echtes OJM-Mapping durchführt (ich nehme an, dass Svenson dies auch tut, aber zusätzlich), wie zum Beispiel:

Auch wenn Sie sowohl XML als auch JSON unterstützen müssen, sollten Sie IMO besser getrennte Bibliotheken für diese Aufgaben verwenden - Objekte (Beans), die auf der Serverseite verwendet werden, müssen nicht anders sein, nur Serialisierungsbibliotheken, die konvertieren zu / von xml und json.

    
StaxMan 11.05.2009, 18:50
quelle
0

Mir ist klar, dass das Thema nicht stimmt, aber ich möchte eine Lösung in svenson JSON .

Benötigen Sie wirklich öffentliche Felder in Ihren Domain-Klassen? Abgesehen davon, dass Eigenschaften verwendet werden müssen, kann Svenson Fälle wie diese mit einer einfacheren JSON-Ausgabe mit einer Diskriminatoreigenschaft behandeln

%Vor%

würde JSON wie

ausgeben %Vor%

welches mit einem Code wie diesem erneut geparst werden könnte

%Vor%     
fforw 07.05.2009 21:34
quelle
0

Ein Svenson-Typ-Mapper, der auf dem vollständigen Klassennamen basiert, würde ungefähr so ​​aussehen:

%Vor%

Dies ist keine ideale Implementierung, da sie die Konfiguration von PropertyValueBasedTypeMapper erbt, ohne sie wirklich zu benötigen. (sollte eine sauberere Version in Svenson enthalten)

Das Setup ist sehr ähnlich wie oben

%Vor%     
fforw 07.05.2009 22:26
quelle