Laufzeitkompatibilitaet von Objekten
Wolfgang Egger
wir entwickeln hier ein verteiltes componentenbasiertes System. Die
einzelnen Componenten tauschen untereinander Daten, die in Message-Klassen
gekapselt sind. Dabei werden die auszutauschenden Klassen serialisiert und
via UDP oder TCP uebertragen.
Das waere alles wunderbar, wenn nicht des oefteren "ClassCast" - Exeptions
auftreten wuerden. Ob eine solche Exception auftritt oder nicht, scheint vom
Compiler, mit dem die zu serialisierende Klasse compiliert wurde
abzuhaengen. Sie treten offenbar auf, wenn innerhalb des Gesamtsystems
unterschiedliche Compiler verwendet wurden. Wunderlicherweise lassen sich
jedoch einige Klassen serialisieren und andere nicht, obwohl sie mit dem
selben Compiler compiliert wurden.
Ich vermute mal, dass die unterschiedlichen serialVersionUIDs des Pudels
Kern sind. Gibt es eine Moeglichkeit diese z.B. beim compilieren irgendwie
zu beeinflussen, oder dem Serialisierungsmechanismus abzugewoehnen diese zu
beachten?
Es kann doch nicht Sinn der Sache sein, dass in einem verteilten System alle
beteiligten Componenten immer mit dem selben Compiler und/oder JDK
kompiliert werden muessen. Ich bin fuer alle Hinweise und Ratschlaege
unendlich dankbar, da ich nur, wenn ich dieses Problem aus der Welt schaffe,
die IDE meines Vertrauens (Visual Age 3.5) benutzen kann.
Abschlissend die Fehlermeldung
Thanx in advance
Wolfgang
java.io.InvalidClassException: caprix.basic.MessageID; Local class not
compatible: stream cl
assdesc serialVersionUID=-890177246365232552 local class
serialVersionUID=246965286886020550
5
at java.io.ObjectStreamClass.validateLocalClass(Unknown Source)
at java.io.ObjectStreamClass.setClass(Unknown Source)
at java.io.ObjectInputStream.inputClassDescriptor(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.io.ObjectInputStream.inputObject(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.io.ObjectInputStream.inputClassFields(Unknown Source)
at java.io.ObjectInputStream.defaultReadObject(Unknown Source)
at java.io.ObjectInputStream.inputObject(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.io.ObjectInputStream.inputClassFields(Unknown Source)
at java.io.ObjectInputStream.defaultReadObject(Unknown Source)
at java.io.ObjectInputStream.inputObject(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at
caprix.cip.LogicalTransportLayer.receiveMessage(LogicalTransportLayer.java:1
18)
at
caprix.cip.PhysicalTransportLayer.receiveMessage(PhysicalTransportLayer.java
:130)
at caprix.cip.PTLReceiver.proceedElement(PTLReceiver.java:164)
at caprix.util.Queue.run(Queue.java:155)
Christian Wederhake
news:kelc29...@news.equityscope.com...
> [...]
> Ich vermute mal, dass die unterschiedlichen serialVersionUIDs des Pudels
> Kern sind. Gibt es eine Moeglichkeit diese z.B. beim compilieren irgendwie
> zu beeinflussen, oder dem Serialisierungsmechanismus abzugewoehnen diese
zu
> beachten?
Diese Vermutung liegt naha.
Loesung:
Auf eine Klasse das im JDK enthaltene Tool "serialver" anwenden.
Den dort erhaltenen Wert dann einfach in folgender Worm in die Klasse
aufnehmen:
class Message extends Object implements Serializable {
private static final long serialVersionUID = xxxxxxxxxxxxxxxxL;
// ...
}
Ciao
Chris
--
Christian Wederhake
Privat : caw...@cawgod.com
Java-Fragen : ja...@cawgod.com
Wolfgang Egger
Christian Wederhake <caw...@cawgod.com> schrieb in im Newsbeitrag:
92cn70$3er$1...@kilbeggan.xlink.net...
> Loesung:
> Auf eine Klasse das im JDK enthaltene Tool "serialver" anwenden.
> Den dort erhaltenen Wert dann einfach in folgender Worm in die Klasse
> aufnehmen:
>
> class Message extends Object implements Serializable {
> private static final long serialVersionUID = xxxxxxxxxxxxxxxxL;
> // ...
> }
>
Jou, this was it!
Danke sehr vielmals!
Wolfgang