Hej Daniel,
Kann ich das in irgendeinerweise umgehen?
Damit kenne ich mich nicht aus. Es könnte sein, dass das implementierungsabhängig ist. Vernünftige Datenobjekte sollten aber sehr leicht serialisierbar sein.
Geht so, ich möchte in meine Session zwei Objekte stecken. Beide sind Typen von der gleichen Superklasse. Diese kassiert wiederrum Objekte in verschiedenen Collections-Implementierungen, die zudem auch noch in beiden erstgenannten Klassen identisch sein müssen, also stark vereinfacht so:
------------------- ----------------------- -------------------
| class C | | class R | | class P |
------------------- ----------------------- -------------------
| final Set<P> ps | | final Map<P,Long> m | | final String id |
| final Set<R> rs | ----------------------- -------------------
-------------------
| |_____________
| |
v v
--------------- ----------------
| class A | | class B |
| extends C | | extends C |
--------------- ----------------
Also A und B teilen sich gleiche Instanzen von P und R. Deswegen kann ich eben nicht einfach A und B serialisierbar machen, wenn Sichergestellt sein muss, dass sie nach dem Deserialisieren auf gleiche Objekte zugreifen.
Um ein Objekt serialisierbar zu machen, genügt es schon [...] keine Eigenschaften als final zu deklarieren.
Das wäre der Gau, allerdings würde das die Funktionsweise von readObject( ObjectInputStream)
erklären. Ich würde also erst eine neue "leere" Instanz erzeugen und dann mit readObject, lediglich die Felder füllen?
Die Objekte nach XML zu serialisieren ist keine gute Idee. Ein ObjectStream erlaubt es, direkt Objekte, Arrays usw. auszugeben. Dadurch wird der Implementierung erlaubt, diese Datenstrukturen in einem optimierten Format zu speichern. Wenn Du erst mal XML daraus machst, ist diese Möglichkeit weg.
Meine gesamte Datenstruktur baut auf einem verbreitetem XML-Schema auf, weshalb ich eben Methoden und Klassen zum Speichern und Lesen sowieso schon implementiert habe.
Statt zu beschreiben, wie man ein Objekt serialisiert, kann es einfacher sein, einfach ein einfaches anderes Objekt zu erzeugen, und dieses stattdessen zu serialisieren. (Siehe writeReplace und readResolve)
Das muss ich mir nochmal anschauen. Vielleicht könnte das helfen. Meine letzte Idee war jetzt um A und B einen Wrapper zu bauen der Serialisierbar ist und somit wenigstens das Problem der gemeinsamen Objekte umgeht. Aber dass die einzelnen Felder der enthaltenen Klassen nicht final sein dürfen hör ich jetzt zum ersten mal und daran wird wohl so einiges scheitern ... Scheint fast so, als wenn das einfachste wäre auf die Session-Implementierung zu verzichten und diese selber "nachzubauen".
Dank Dir in jedem Fall für Deine ausführliche Beschreibung.
Beste Grüße
Biesterfeld
Art.1: Et es wie et es
Art.2: Et kütt wie et kütt
Art.3: Et hätt noch immer jot jejange
Das Kölsche Grundgesetz