[JSP/Servlet] Eccezioni sollevate apparentemente impossibili

[LeleFT]

Buongiorno a tutti.
Mi trovo a postare dopo che ho sperimentato, per diversi mesi, delle situazioni di errore decisamente strane e controverse. L'ultima mi ha convinto a postare perchè forse sto sbagliando qualcosa.

Mi trovo in questa condizione: ho una Servlet (in realtà in più di una capita la stessa cosa) che saltuariamente lancia delle eccezioni che non possono verificarsi (o almeno non potrebbero).

Esempio:

// Recupero la sessione dell'utente, se ne ha una!
HttpSession s = request.getSession( false );

// Controllo se ha una sessione attiva:
if (s == null) {
   // Lo indirizzo verso una pagina d'errore, che gli indica che la sua sessione è scaduta.
   ...
}

Se riesco ad arrivare oltre il primo controllo, mi aspetto che esista una sessione e che essa sia attiva. Ora, se così è (ditemi se sto sbagliando), so per certo che all'interno della sessione esiste un oggetto: infatti ho un SessionListener che, alla creazione di una sessione, crea questo oggetto e lo butta dentro (una volta inserito questo oggetto non viene mai più rimosso fino alla invalidazione della sessione).

Quindi:

DatiUtente utente = (DatiUtente) s.getAttribute("utente");
if ( utente.isAbilitato() ) {
   // L'utente è abilitato a fare certe cose
} else {
   // L'utente non è abilitato a fare cose particolari
}

Ma, magia delle magie, capita che venga lanciata una NullPointerException all'esecuzione di questa seconda if... ergo, l'oggetto DatiUtente è nullo, ergo... che ergo? Che la sessione è scaduta fra il primo ed il secondo if?? Possibile??

Nessun problema insormontabile: ho tapezzato così:

DatiUtente utente = (DatiUtente) s.getAttribute("utente");
if (utente == null) {
   // Faccio finta che la sessione fosse già scaduta
   // e lo mando a spasso lo stesso...
}
if ( utente.isAbilitato() ) {
   // L'utente è abilitato a fare certe cose
} else {
   // L'utente non è abilitato a fare cose particolari
}

Oltre al fatto che la cosa non mi piace (ma non ho trovato altri sistemi più decenti), rende il codice della Servlet un porcile...

Ma veniamo all'assurdo: ho una bella pagina HTML con un form, grossomodo così fatto:

<form action="/Servlet?act=pippo" method="post">
   <select name="destinazione" size="1" style="width: 90%">
      <option value="0" selected="selected">Prima opzione</option>
      <option value="1" >Seconda opzione</option>
   </select>
</form>

Fra le varie opzioni presenti all'interno della combo box la prima viene sempre selezionata di default, quindi almeno un valore per quel campo c'è sempre.
Questo è il codice che raccoglie quel valore:

   ...
   String dst = request.getParameter("destinazione");
   int indice = Integer.parseInt( dst );

Oggi quel codice mi ha sollevato la seguente eccezione:

NumberFormatException: null
   at java.lang.Integer.parseInt(unknown source)
   ...

Domanda: ma come è possibile che sia arrivato un valore nullo se almeno un valore è sempre selezionato?? Da notare che la parte di codice che ho postata è subordinata all'esistenza di una sessione attiva...

Chiedo lumi a chi con le Servlet ci programma da più tempo di me...


Ciao.

[R@ve M@ster]

Originariamente inviato da LeleFT
infatti ho un SessionListener che, alla creazione di una sessione, crea questo oggetto e lo butta dentro (una volta inserito questo oggetto non viene mai più rimosso fino alla invalidazione della sessione).

Che sia proprio qui l'nghippo? Magari c'è qualcosa che non quadra nella creazione.

Per il secondo punto:


<select id="destinazione" size="1" style="width: 90%">

Così dovrebbe andare

[LeleFT]

Innanzitutto grazie per la risposta.

Originariamente inviato da R@ve M@ster
Che sia proprio qui l'nghippo? Magari c'è qualcosa che non quadra nella creazione.

Dubito fortemente: il sito ha una frequenza di circa 500-600 visite al giorno, ognuna delle quali rimane nel sito, mediamente, 1 ora e mezza... se così fosse accadrebbe ben più frequentemente.... (forse non avevo ritenuto necessario dirlo: la cosa non capita sistematicamente, ma casualmente...)

Per il secondo punto:


<select id="destinazione" size="1" style="width: 90%">

Così dovrebbe andare

Domanda: id identifica univocamente una entità all'interno della pagina... ma non è il "name" ad essere essenziale per la getParameter()? Cioè... perchè avrebbe funzionato finora? Non è l'unica combo box che ho nel sito e tutte le altre (compresa questa) hanno sempre funzionato alla perfezione... anche in questo caso, infatti, si è trattato di un caso eccezionale, non è la norma.


Ciao.

[R@ve M@ster]

Avevo lo stesso problema e l'ho risolto identificando gli elementi con l'id e non con il name.
L'attributo name non lo utilizzo mai e il request.getParameter mi preleva correttamente i valori degli elementi identificati dal solo attributo id.

Tra le altre cose stando alle regole l'attributo id è obbligatorio (per gli elementi che lo prevedono) mentre l'attributo name per alcuni elementi è stato addirittura deprecato, sintomo questo della diversa utilità/potenzialità dei due attributi.

[Santinizer]

NumberFormatException: null

io ti consiglierei di usare, almeno temporaneamente, un try-catch e loggare oltre al NumberFormatException anche lo User-Agent della request e/o l'indirizzo IP in modo da capire se il problema è dovuto sempre allo stesso richiedente

[LeleFT]

Originariamente inviato da R@ve M@ster
Avevo lo stesso problema e l'ho risolto identificando gli elementi con l'id e non con il name.
L'attributo name non lo utilizzo mai e il request.getParameter mi preleva correttamente i valori degli elementi identificati dal solo attributo id.

Tra le altre cose stando alle regole l'attributo id è obbligatorio (per gli elementi che lo prevedono) mentre l'attributo name per alcuni elementi è stato addirittura deprecato, sintomo questo della diversa utilità/potenzialità dei due attributi.

E questo lo posso anche fare... non mi costa nulla, se non in termini di tempo.

Originariamente inviato da Santinizer
io ti consiglierei di usare, almeno temporaneamente, un try-catch e loggare oltre al NumberFormatException anche lo User-Agent della request e/o l'indirizzo IP in modo da capire se il problema è dovuto sempre allo stesso richiedente

Questo potrebbe essere interessante e non ci avevo proprio pensato. Rimarrà un problema da risolvere nel caso l'eccezione si verifichi sempre in determinate condizioni...


Ciao.

[Santinizer]

Se l'unico problema è legato al fatto che ti arriva un valore null per un parametro e tu conosci il valore di default per quel parametro puoi sempre settarlo a priori

String dst = request.getParameter("destinazione"); 
int indice = 0;//valore di default 
try{ 
     indice = Integer.parseInt( dst ); 
}catch(NumberFormatException e){} 

considera anche che è possibile richiamare l'url ".../Servlet?act=pippo" non attraverso un browser e la form da te definita ma attraverso uno script (in grado di mantenere la sessione). A titolo di esempio esiste la classe WebConversation nelle API HttpUnit in grado di mantenere la sessione, di trovare una form(WebForm) all'interno di una parina web e di richiamarne la servlet definita nell'attributo action in modo molto semplice. In questo modo si può facilmente richiamare la tua servlet all'interno di una sessione attiva sul server evitando di inviare il parametro "destinazione".

Ultimo scenario possibile che mi viene in mente per il tuo problema, soprattutto se usi i Filtri o meccanismi di autenticazione basati su Realm, è che qualcuno apra la sessione, si porti sulla pagina successiva alla form, faccia scadere la sessione e clicca su "aggiorna" ; non ho verificato ma secondo me potrebbero esserci problemi.

[LeleFT]

Tutto molto interessante, ma non applicabile al mio caso.
Il sito in questione è un e-commerce, con autenticazione delegata ad un sistema legacy (la faccio semplice ).

Valori di default, purtroppo non ne ho, perchè, nel particolare esempio, il "valore di default" per quel parametro varia da utente a utente.

Ultimo scenario possibile che mi viene in mente per il tuo problema, soprattutto se usi i Filtri o meccanismi di autenticazione basati su Realm, è che qualcuno apra la sessione, si porti sulla pagina successiva alla form, faccia scadere la sessione e clicca su "aggiorna" ; non ho verificato ma secondo me potrebbero esserci problemi.

Questo non dovrebbe accadere: se la sessione scade, tutti gli oggetti in essa contenuti dovrebbero essere distrutti (almeno per come l'ho sempre saputa io... se così non fosse vorrei avere altre informazioni a riguardo), ivi compresi tutti gli oggetti che vado a testare prima di effettuare l'operazione incriminata. Inoltre, in tutte le servlet, prima di effettuare qualunque tipo di operazione, testo l'esistenza di una sessione attiva (in particolare, quella pagina viene visualizzata se e solo se l'utente è loggato e la sua sessione non è scaduta).

Ciao.

[Santinizer]

Originariamente inviato da LeleFT
Questo non dovrebbe accadere: se la sessione scade, tutti gli oggetti in essa contenuti dovrebbero essere distrutti (almeno per come l'ho sempre saputa io... se così non fosse vorrei avere altre informazioni a riguardo), ivi compresi tutti gli oggetti che vado a testare prima di effettuare l'operazione incriminata. Inoltre, in tutte le servlet, prima di effettuare qualunque tipo di operazione, testo l'esistenza di una sessione attiva (in particolare, quella pagina viene visualizzata se e solo se l'utente è loggato e la sua sessione non è scaduta).

Usando l'autenticazione basata su Realm succede che se sei su una pagina Px qualsiasi e fai scadere la sessione, cliccando su aggiorna vieni redirezionato alla pagina di login e poi(se l'autenticazione va a buon fine) automaticamente sulla pagina Px. In questo passaggio può succedere che magari i parametri post si possano 'perdere'... Ma evidentemente non è il tuo caso, come non detto.

Originariamente inviato da LeleFT
Valori di default, purtroppo non ne ho, perchè, nel particolare esempio, il "valore di default" per quel parametro varia da utente a utente.

Penso che tu abbia definito la tua form in una JSP in modo da definire tale form in maniera dinamica rispetto all'utente loggato (che si trova nella sessione)... Non puoi usare lo stesso meccanismo per assegnare il valore di default al parametro nella servlet?

[LeleFT]

Originariamente inviato da Santinizer
Penso che tu abbia definito la tua form in una JSP in modo da definire tale form in maniera dinamica rispetto all'utente loggato (che si trova nella sessione)... Non puoi usare lo stesso meccanismo per assegnare il valore di default al parametro nella servlet?

Certo, potrei... ma se il cliente mi chiede di spedire la merce a Milano e io, per un errore di quel tipo, gliela mando per default a Roma, il cliente potrebbe non essere così contento...

Comunque, a me interessava capire più che altro in quali circostanze e/o per quali motivi potesse accadere una cosa del genere...

Vabbè, intanto modifico il modificabile.


Ciao.