Newsgroup: it.comp.java
Titolo: disperato bisogno di aiuto su serializzazione

ciao a tutti
ho un grosso (almeno per me) problema a leggere un oggetto da un file,
o meglio a castare l'oggetto... sembra incredibile ma è così. sentite
cosa succede:
1. l'istruzione che causa l'eccezione è un cast. la prima cosa strana
   è che il cast e l'oggetto in cui casto sono di una superclasse della
	 classe che leggo. sono sicuro, visto che un getClass().getName()
   sull'oggetto che leggo è una sottoclasse (PPDLnode è il nome della
   superclasse, Pdef è quello della sottoclasse).
2. l'eccezione ClassCast... non è relativa a nessuna di queste classi!
   è relativa ad una classe chiamata Wrapper1 le cui istanze, nel
	 codice (non mio) che serializza l'oggetto dovrebbe essere disgiunta
	 da Pdef... per sicurezza ho fatto una massiva modifica di Pdef e di
	 tutte le classi degli oggetti nestati/riferiti (almeno credo che
	 siano tutti) in modo che i valori che finiscono nelle variabili di
	 istanza siano copie degli originali, almeno fino al "secondo
	 livello"... Wrapper1 comunque è nel classpath.
3. se, invece di fare un getClass().getName(), faccio un toString()
   sull'oggetto caricato, ottengo qualcosa del formato
   Pdef@<id1>
	 Wrapper1@<id2>
4. questo è il massimo della follia. se non ho le traveggole,
	 l'eccezione viene throwata, ma le istruzioni dopo il cast...
	 vengono eseguite!!!
5. per evitare problemi di versioning o cose del genere, ho
	 ricompilato da zero il codice che genera quella roba, e l'ho fatto
	 rigenerare
6. uso l'ultima versione disponibile del jdk 1.1 per linux.
a questo punto sono giorni che provo a risolvere questa sciocchezza, e
non ne vengo a capo... vi prego, se avete un'idea, fatemi sapere.
rischio di mancare una deadline importantissima, e quel che è peggio,
non so che pesci pigliare...
da dove viene quel wrapper1? perchè spunta nel cast di classi
completamente diverse? è normale che ne veda il "fantasma"
nell'oggetto che carico? perchè quel comportamento insolito delle
eccezioni?
ciao e grazie in anticipo, gabriele.
-- 
http://gz.freeweb.org

ciao e grazie in anticipo, gabriele.
Non capisco granche', in particolare dove dici "l'eccezione ClassCast...  è 
relativa ad una classe chiamata Wrapper1 le cui istanze, nel codice (non mio) 
che serializza l'oggetto dovrebbe essere disgiunta da Pdef" ... "Wrapper1 
comunque è nel classpath."
Della prima frase non colgo il senso. Della seconda, Wrapper1 e' una classe 
della tua applicazione, o cosa? Ne parli come se no, ma che c'entra allora che 
e' in classpath? L'implementazione della serializzazione sotto linux non mi e' 
familiare, temo.
Posta l'eccezione.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 familiare, temo.
Sto lavorando ad un progetto diviso in due parti, c'è una parte del
progetto che è sostanzialmente indipendente dalla mia parte, che è
stata fatta da una "collega", che è quella che produce gli oggetti che
leggo. delle sue classi io uso solo una piccola parte, tutte
sottoclassi di PPDLnode. Wrapper1 NON dovrebbe essere una classe che
mi interessi, visto che è "interna" al funzionamento di quella parte
del progetto ed il suo contenuto non mi interessa tranne che per
qualche informazione che dovrebbe essere copiata negli oggetti che
uso. Insomma io quella classe non dovrei trovarmela fra i piedi; e
invece c'è.
L'eccezione riguarda proprio Wrapper1, come si vede dallo stacktrace
che posto sotto. Ma è relativa ad una istruzione di cast in cui NON
compare Wrapper1 (appunto, io non lo dovrei neanche vedere), e non è
neanche la classe dell'oggetto che leggo.
EngineController che compare sotto è un client RMI che si collega ad
Engine (oggetto remoto) per invocare un determinato metodo. L'errore è
nel metodo in questione.
[tesi@gzuglian prova]$ java EngineController engine1 load gino pino
/home/tesi/ripartenza/0.0.0/plus/ultimo-stadio/prova/projectiondir1
rabbitCompile.Pdef@80db9c0
Salve!
rabbitCompile.Wrapper1@80dc2a6
java.lang.ClassCastException: rabbitCompile.Wrapper1
at Engine.loadInstance(Engine.java:232)
at Engine_Skel.dispatch(Engine_Skel.java:121)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:164)
at sun.rmi.transport.Transport.serviceCall(Transport.java:154)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:600)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:506)
at java.lang.Thread.run(Thread.java)
... e questo è il codice intorno a riga 232. notare il "Salve!"
inframmezzato all'output dell'x.toString()... e dove è nel codice:
PPDLNode node = null;
try {
Object x = ois.readObject();
System.err.println(x.toString());
node = (PPDLNode) x; // questa è riga 232
System.err.println("Salve!");
}
catch(Exception e) { e.printStackTrace(); };
se servono altri dettagli, sono qui.
ciao, gabriele.
-- 
http://gz.freeweb.org

 wrote:
nessuna idea?


 nessuna idea?
Non dovrebbe assolutamente centrare niente, cmq hai provato ad utilizzare
un'altra virtual machine? anche se probabilmente ti da lo stesso errore
potrebbe essere un attimo piu' chiara nel segnarti dove effettivamente
l'errore e'.
boh?
byez
keii.


Scusa, non ho avuto granche' tempo di scrivere.
Mi capito' tempo fa una cosa simile, e non aveva niente a che vedere, in ultima 
analisi, con la serializzazione (anche se l'eccezione era identica). Ricordo il 
problema vagamente: uno dei programmatori aveva commesso un errore 
concettuale; un oggetto A faceva il lookup di un oggetto remoto, e ne invocava 
un metodo. Questo metodo ritornava un reference locale ad un secondo oggetto 
(che implementava comunque Remote, perche' veniva esposto tramite l'ORB per 
altri scopi), di cui venivano poi invocati metodi. Siccome per un oggetto 
remoto sia lo _Stub che l'implementazione vera implementano la *stessa* 
interfaccia, l'assegnamento runtime riusciva senza problemi. Al momento di 
(de)serializzare pero', il tipo atteso era l'implementazione "vera", il tipo 
effettivo era (vista la semantica di RMI) lo _Stub.. ed ecco la castexception.
La cosa si risolse facendo *due* lookup vicendevoli, e scambiandosi quindi solo 
_Stub, e non istanze complete.
Purtroppo non ricordo i dettagli (nemmeno la situazione architetturale precisa, 
come vedi) perche' l'errore non era mio. :)


 come vedi) perche' l'errore non era mio. :)
ringrazio entrambi per l'attenzione, farò ancora un pò di esperimenti
cercando di seguire i vostri consigli sperando che l'errore vada via.
grazie di nuovo
