Newsgroup: it.comp.java
Titolo: Inputstream di ServletRequest

Per diverse ragioni mi trovo a dover accedere a getInputStream piu' di 
una volta. E, come da documentazione, ricevo una IllegalStateException.
C'e' un modo per ovviare a questo problema ? Ma, sopratutto, perche' non 
si puo' accedere all'InputStream piu' di una volta ?

 C'e' un modo per ovviare a questo problema ? 
Non puoi salvare il riferimento in una variabile e riutilizzarlo più tardi?
Posta il codice e spiega dove e perché accedi ad InputStream, vedendo il 
codice ti si può dare qualche consiglio su come modificare il design 
della tua servlet.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

 Non puoi salvare il riferimento in una variabile e riutilizzarlo più tardi?
Anche se salvassi il riferimento all'InputStream, quando cerco di 
leggerci di nuovo ricevo l'exception.
Una sola volta si puo' leggere dall'InputStream di ServletRequest, e non 
ho neppure la possibilita' di salvarne il contenuto una volta letto per 
utilizzarlo la seconda volta (Mi baso su codice vecchio e intoccabile + 
struts 1.0 :( ...)


Non capisco di cosa stai parlando.
Non puoi essere piu' preciso? Qual'e' la documentazione che dice che 
l'InputStream si può leggere solo una volta? Prima però parlavi di 
accedere, adesso di leggere, non puoi semplicemente dire qual'è il 
metodo la cui chiamata genera l'eccezione? O incollare lo stack trace?
Non puoi far vedere il codice? Così capiamo di che metodo stai parlando.
Cosa vuol dire che si puo' leggere solo una volta?
L'unico modo per leggere da un InputStream è usare i metodo read(), 
oppure usare un wrapper(come InputStreamReader) che usa i metodi read.
Vuoi dire che non puoi chiamare più di una volta il metodo read()? Mi 
sembra impossibile.
Sicuramente non puoi leggere dopo aver invocato il close().



Ti rispondo cosi su sue piedi perche' sono un po' incasinato.. quindi
prendi quel che dico con le molle..credo che il problema possa essere
questo.. non e' che prima hia cercato di leggere dati della richiesta
"alla solita maniera" (tipo request.getParameter etc.) e poi cerchi di
impipargli l InputStream?
Se non ricordo male l InputStream e' leggibile solo se non hai provato
a leggere la richiesta in arriva in altro modo..

 wrote:

oops sorry avevo letto male.. quinid tu lo sai gia' che non puoi
tentare di leggere i dati piu' di una volta.Immagino che il motivo sia
che visto che qui parliamo di dati che ti arrivano da una
comunicazione di rete, sono transiente, non e' che te li puoi
rileggere cento volte come se fossero in un file... Comunque direi che
la cosa da "curare" e' il design orribile che ti obbliga a 1) usare l
inpuStream 2) usarlo due volte!!!!

 impipargli l InputStream?
Esatto :)
Il problema nasce dal fatto che il MultipartRequestWrapper di Struts non 
ha la Map per i requestParameter popolata quando avviene un reset() del 
form-bean. Se la popolo (Leggendo, appunto, dall'inputStream del 
ServletRequest), piu' tardi quando Struts cerca di popolare il 
form-bean, fallisce.
Spero di essere stato abbastanza chiaro ;)

 inpuStream 2) usarlo due volte!!!!
Il design orribile e' responsabile solo in parte. Il "grande colpevole" 
e' Struts che mi wrappa il request in un MultipartRequestWrapper senza 
popolare i requestParameters. O, meglio, li popola troppo tardi per me 
(O per il "framework" orribile sul quale mi devo basare).

 (O per il "framework" orribile sul quale mi devo basare).
mi sfugge però qual'è il problema, nel dettaglio.
non mi risulta che per accedere ai parametri della request si debba 
accedere all'inputstream...
forse se posti le due righe di codice che accedono all'inputstream e che 
danno errore ci capiamo meglio...
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 Spero di essere stato abbastanza chiaro ;)
E un progetto di lavoro? Un progetto tuo? Il discorso e' che Struts e'
li' proprio per evitarti di fare le cose di basso livello.
Se hai bisogno di farle lo stesso per qualche motivo (integrazione con
un tuo framework) alla fine da solo fastidio (come dimostra il tuo
caso) Quindi invece di creare un accrocchio ibrido tra un tuo
framework e struts io ti consiglio di buttare a mare uno dei due.
Se proprio ci tieni puoi , per questa singola pagina  non passare
attraverso struts e gestirtela solo con servlet + jsp nudi..e' anche
questo un piccolo accrocchio ma potrebbe mettere una toppa finche' non
ti viene in mente una soluzione finale..?

 li' proprio per evitarti di fare le cose di basso livello.
Un progetto di lavoro. Grossa banca. Codice vecchio, fermi a Java 1.4. 
Molto conservatori, impossibile modificare il codice esistente :(
E' tutto il finesettimana che ci penso, e vedo due soluzioni:
- Come hai detto te, caso speciale e bypassare struts
- Dire chiaramente che questa "ficiur" non e' implementabile. Non 
sarebbe la prima volta, noi tutti sappiamo che il cliente chiede la luna 
ma poi per restare nel budget si accontenta di un sassolino ;)
Pero' resta la curiosita' di sapere come altre persone hanno risolto 
questo problema, che immagino non sia capitato solo a me.

 danno errore ci capiamo meglio...
Naaaa, non voglio sprecare il vostro tempo per un problema non 
fondamentale ;)
Semplicemente speravo che qualcuno tirasse fuori dal cilindro la 
soluzione :)

 fondamentale ;)
Si spreca più tempo cercando di capire qual'e' il problema quando manca 
il codice.


 il codice.
Difficile far uscire il codice dalla banca :/ ... Dovrei stamparmelo su 
carta e "ritiparlo" a casa. Vedro' cosa si puo' fare ...


Non è necessario che posti il codice usato nella banca, basta che fai un 
SSCCE che riproduce il problema.
Poi non so se puoi accedere a usenet durante l'orario di lavoro (magari 
con Goggle Groups se ti filtrano tutte le porte a parte l'80).
Certo che portarsi a casa il codice e riscriverlo solo perché al lavoro 
non ti danno la possibilità di chiedere aiuto come si deve mi pare 
brutto, vale la pena di utilizzare la frase "Non si può fare".
