Qualche anno fa ritenevo impossibile fare debugging di applicazioni web.
Mi chiedevo in particolar modo come fosse possibile raggruppare all’interno di un unico debugger la componente client side (cioè il mix di codice html+css+javascript eseguito nel browser) con la componente server side (in qualsiasi forma si presentasse: php, java, dot.net).
Ultimamente molti framework, così come importanti application server con il loro IDE associato, sono riusciti a colmare questa mancanza ed ad offire a noi poveri sviluppatori il nostro caro e provvidenziale debugger.
In realtà in questo articolo non spiegherò come sia possibile fare debugging di entrambe le componenti (client e server) in un’unico IDE bensì mi concentrerò solamente sulla parte server, che ho sempre considerato la più spinosa.
La parte client, in realtà, dà spesso meno noie. Il suo comportamento è più facilmente intuibile e spesso è sufficiente fare delle stampe extra di codice html o qualche alert javascript per poter venire a capo dei problemi (anche se non dobbiamo dimenticare l’utilissimo Firebug in Firefox, di cui ho parlato anche ieri, che permette di fare debugging anche del Javascript lato client).
Oggi voglio parlare del debugging server side di applicazioni web per il mondo Java e in particolare della modalità fornita da Eclipse chiamata “Remote Java Application”. E’ una modalità tale per cui è possibile avviare la JVM con un demone in ascolto su una determinata porta. A questa porta, IDE opportunamente istruiti (quale ad esempio Eclipse), possono collegarsi e dialogare con la JVM stessa.
La JVM segnala all’IDE la riga in quel momento in esecuzione e riceve dall’IDE stesso dei comandi in merito all’esecuzione del codice: breakpoint, step-into, step-over, stato delle variabili, …
Per arrivare a poter debuggare la nostra JVM remota, dobbiamo essenzialmente eseguire due passi: avviare la JVM di Tomcat con degli opportuni parametri per la modalità “remote instance” e indicare al nostro IDE, per il nostro progetto da debuggare, qual è la porta della JVM a cui collegarsi.
Cominciamo con la parte di modifica dell’avvio di Tomcat:
- scegliere una porta libera su cui mettere in ascolto la JVM di Tomcat. Per questo esempio useremo la porta 5050
- individuare il file startup.sh all’interno della nostra distribuzione Tomcat (la versione di Tomcat di questo post è la 6, ma tale procedura è ugualmente applicabile alla versione 5.5)
- modificare l’ultima riga di tale file in questo modo
# vecchia riga
# exec "$PRGDIR"/"$EXECUTABLE" start "$@"
# nuova riga
export JPDA_TRANSPORT=dt_socket
export JPDA_ADDRESS=5050
exec "$PRGDIR"/"$EXECUTABLE" jpda start "$@"
- controllare che, dopo aver avviato Tomcat, la JVM sia effettivamente in ascolto
telnet localhost 5050
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Abbiamo terminato con le modifiche alla sequenza di avvio di Tomcat. Passiamo ora ad Eclipse.
Dopo aver scelto il progetto che vogliamo debuggare, le cui classi compilate devono essere in esecuzione all’interno di una webapp del nostro application server Tomcat, dobbiamo creare una nuova istanza di compilazione di tipo “Remote Java Application“.
- dal menu “Run” di Eclipse scegliamo la voce: “Debug…”
- scorriamo fino alla voce “Remote Java Application” e scegliamo “New” utilizzando il tasto destro del mouse
- diamo un nome alla nostra istanza di debug e modifichiamo la porta di default con la porta scelta 5050
- a questo punto clicchiamo su Debug. Se tutto va bene Eclipse dovrebbe essere in grado di connettersi e dialogare con la nostro JVM in esecuzione con Tomcat
Ora viene la parte più bella!
Iniziamo a impostare dei breakpoint nei punti di codice che vogliamo controllare e facciamo sì che il flusso di esecuzione arrivi in quel punto.
Magicamente potremmo vedere tutti i nostri oggetti Java materializzarsi. Possiamo esaminarne tutte le proprietà, impostare delle espressioni di controllo, entrare e uscire dalle funzioni.
Un aspetto decisamente divertente è l’interazione con il browser. Interrompendo il flusso di esecuzione della JVM interrompiamo ovviamente anche la risposta del server verso il browser. Il cursore di attesa del nostro amato Firefox girerà finché non avremo terminato il controllo del nostro codice e lanceremo il nostro ultimo F8.
Nel caso di debug di applicazioni web AJAX tale possibilità di sviluppo facilita ulteriormente le cose. In questi casi infatti è meno banale controllare i dati restituiti dal server in quanto non compongono quasi mai una pagina html ispezionabile bensì solamente delle porzioni di codice XML o del Javascript serializzato in formato JSON.
Spero che l’articolo vi sia tornato utile; commenti e osservazioni sono sempre molto ben accetti.
) apparire nelle schermate del programma.
