Informatica Sperimentale 07-08 [IS]

jet ha scritto:

phizgerald ha scritto:

jet ha scritto:

raga... miseria zozza... ma c'è un modo per far serializzare/deserializzare oggetti complessi (che abbiano più dei soliti get e set dei bean) -per esempio le classi entità come elemento, rivista, libro, etc, etc- senza generare eccezioni nel parsing passando da server a client o viceversa???? Tra l'altro il comportamento di sto maledetto axis non si capisce... la classe titolare viene serializzata e ricomposta corretamente convertendo i metodi che restituiscono hastable in hashmap, mentre con cliente non c'è alcun problema (anche passando dei vector di cliente) anche lasciando tutto così com'è....
sto esaurendo!!!

HELP!

io invece sto riscontrando problemi con i vector<cliente> . posso chiederti come hai risolto?

sul lato Client:
innanzitutto ho rimosso il metodo getDisplay dall'entità Cliente e poi ho fatto il mapping:
cll.registerTypeMapping(Cliente.class,qnameProd,BeanSerializerFactory.class,BeanDeserializerFactory.class);

sul lato Server:
ho replicato l'entità (sempre senza getDisplay) e ho aggiunto nel wsd il mapping per il tipo Cliente
<beanMapping qname="myNS:Cliente" xmlns:myNS="urn:BiblioService" languageSpecificType="java:BiblioService.entity.Cliente"/>


tutto qui. a me funziona, ma considera che ho installato xerces come serializzatore/deserializzatore
xerces.apache.org/xerces2-j/index.html

Io ho tarsformato in Cliente[] piuttosto che Vector<Cliente>... e finalmente funziona!

Fatto... ho avuto lo stesso problema anch'io... e mi sono affidato al buon Hashtable... che poi axis mi riduce a HashMap sul lato client (che sia mutazione genetica? )...

ora il dubbio è sui fogli di report...

quoto Ing.Cane sul numero di LOC...

inoltre aggingerei... alle LOC ci vanno anche gli xml del SOAP?

altro dubbio... nel campo giorno... che ci va?

/D

Dott.Cane ha scritto:

Ma nel LOC vanno calcolate anche jsp, html, etc??

Credo di sì.

Per quanto riguarda la storia del Vector<Cliente> a me ha funzionato e ho fatto come ha detto jet kid prima, senza usare però xerces (axis e basta) e senza togliere il metodo getDisplay (che ho utilizzato nella jsp).

Ciao

jet ha scritto:

phizgerald ha scritto:

jet ha scritto:

raga... miseria zozza... ma c'è un modo per far serializzare/deserializzare oggetti complessi (che abbiano più dei soliti get e set dei bean) -per esempio le classi entità come elemento, rivista, libro, etc, etc- senza generare eccezioni nel parsing passando da server a client o viceversa???? Tra l'altro il comportamento di sto maledetto axis non si capisce... la classe titolare viene serializzata e ricomposta corretamente convertendo i metodi che restituiscono hastable in hashmap, mentre con cliente non c'è alcun problema (anche passando dei vector di cliente) anche lasciando tutto così com'è....
sto esaurendo!!!

HELP!

io invece sto riscontrando problemi con i vector<cliente> . posso chiederti come hai risolto?

sul lato Client:
innanzitutto ho rimosso il metodo getDisplay dall'entità Cliente e poi ho fatto il mapping:
cll.registerTypeMapping(Cliente.class,qnameProd,BeanSerializerFactory.class,BeanDeserializerFactory.class);

sul lato Server:
ho replicato l'entità (sempre senza getDisplay) e ho aggiunto nel wsd il mapping per il tipo Cliente
<beanMapping qname="myNS:Cliente" xmlns:myNS="urn:BiblioService" languageSpecificType="java:BiblioService.entity.Cliente"/>


tutto qui. a me funziona, ma considera che ho installato xerces come serializzatore/deserializzatore
xerces.apache.org/xerces2-j/index.html

cioè in pratica che hai fatto hai copiato così come è la riga sul client (prima o dopo di invoke??)
e per il server come hai personalizzato la riga dell'xml??

ma voi avete creato un unico webservice che ha i diversi metodi richiesti oppure avete creato 3 webservice, ognuno per un metodo distinto?

phizgerald ha scritto:

ma voi avete creato un unico webservice che ha i diversi metodi richiesti oppure avete creato 3 webservice, ognuno per un metodo distinto?

1 servizio, 3 metodi