CORSO DI JSP

Il Servlet Container Apache Tomcat

Cos'è Tomcat?
Dove lo trovo?
Installazione
Variabili d'ambiente
Directory
Start/Stop di Tomcat
Deployment di una applicazione
Come funziona Tomcat?
Reloading di una applicazione

Cos'è?

Tomcat è un Servlet/JSP container che risponde alle specifiche dell'architettura J2EE e si situa nella zona WEB/EJB Container.

Dove lo trovo?

È un prodotto opensource dell'Apache Group, si può scaricare gratuitamente da http://jakarta.apache.org. E' disponibile per diverse piattaforme, tra cui le più popolari tra gli studenti: Microsoft Windows e Linux.
Va installato nella macchina che si vuole utilizzare come web application server.

Gli URL per i due sistemi operativi sono:
Windows
Linux

Installazione

La prima cosa da fare è procurarsi un JDK (Java Development Kit); infatti il server Tomcat si appoggia su un ambiente di sviluppo per Java, in particolare su un COMPILATORE JAVA che è disponibile nel JDK. Ciò permette, oltre a fare funzionare Tomcat, anche di sviluppare Javabeans o applet Java o applicazioni client Java. La versione che è necessaria e sufficente è dalla 1.2 in su, si può scaricare gratuitamente il software dal sito della Sun Microsystems:

http://java.sun.com/j2se/.

Una volta effettuato il download, eseguire l'installazione seguendo le istruzioni accluse nella release.

Importante: impostare una variabile d'ambiende JAVA_HOME (comando set per Windows, comando export per Linux) contentente il path verso la directory di installazione.

Nel mio PC,

C:\Documents and Settings\Administrator>set JAVA_HOME
JAVA_HOME=C:\j2sdk1.4.1_01

La seconda cosa da fare è scaricare Tomcat (la Binary Distribution) dal sito indicato nel punto precedente e lanciare l'installazione. E' conveniente salvare la distribuzione in una directory standard che nominerete con jakarta-tomcat-4.0 oppure /opt/jakarta/tomcat/ se usate Linux; in MS Windows i file vengono installati di solito sotto C:\Programmi\Apache Group\Tomcat 4.1\. In ogni caso, il nome di questa directory lo salverete (set oppure export) in una variabile di ambiente che di solito viene chiamata CATALINA_HOME. Ulteriori notizie sulle variabili d'ambiente si trovano al punto successivo.

Nel mio PC:

C:\Documents and Settings\Administrator>set CATALINA_HOME
CATALINA_HOME=C:\Programmi\Apache Group\Tomcat 4.1\

Variabili di ambiente

All'atto dell'installazione, Tomcat definisce una struttura di directory ed inizializza un certo numero di variabili d'ambiente; le cito qui per nome e si ricordi che per citarle all'interno di comandi e script in Linux si prepone il simbolo $ mentre in Windows si usa % come prefisso e postfisso.

Per impostare una variabile di ambiente:

Linux: da linea di comando (aprite una consolle) usare il comado export:
```
[root@bach /etc]# export CLASSPATH=$CLASSPATH:$CATALINA_HOME/shared/lib
```
Fine.
Windows: da linea di comando (aprite un Prompt dei comandi) usare il comado set:
```
C:\> set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%lib\shared
```
Non è finita.
Dovete andare in Start - Pannello di Controllo - Sistema - Avanzate, in basso c'è un pulsante "Variabili d'ambiente", premetelo, evidenziate la riga con CLASSPATH e premete "Modifica"; riportate nel testo lo stesso testo che avete immesso a sinistra dell'= nell'espressione DOS; premete OK. Se non fate questa modifica, alla prossima riaccensione di Windows non avrete le ultime modifiche fatte da DOS. Per contro, se modificate solo da questa interfaccia CLASSPATH, il sistema non sentirà la variazione e per fargliela sentire dovrete riavviare Windows...

Le variabili d'ambiente con le quali dovete imparare a destreggiarvi sono:

CATALINA_HOME: è la directory di lavoro del server (in cui risiede tutto, dagli eseguibili che costituiscono il server, ai parametri di configurazione, alle applicazioni web). Può essere:
- /opt/jakarta/tomcat/ ($CATALINA_HOME) in Linux
- C:\Programmi\Apache Group\Tomcat 4.1\ (%CATALINA_HOME%) in Windows
CLASSPATH: è IMPORTANTISSIMA, è la variabile che serve per dire al compilatore Java dove trova le librerie di classi o le classi singolarmente compilate che servono all'applicazione JSP. Nella CLASSPATH vanno citati tutti i percorsi che portano ai file .class che si intendono utilizzare all'interno degli script JSP.
Particolarmente importante è includere sempre nella CLASSPATH il percorso . che significa che quando compileremo una classe locale alla nostra applicazione questa potrà essere recuperata nella cartella WEB-INF/classes della nostra applicazione senza dover specificare tutto il percorso; inoltre così non saremo costretti a specificare il percorso verso le classi locali per OGNI applicazione JSP che scriviamo. Più avanti un esempio ci chiarirà il tutto. I valori per CLASSPATH possono essere ad esempio:
```
$CATALINA_HOME/webapps/mia_applicazione/WEB-INF/classes/form/
```
se, ad esempio, nella directory classes c'è un package (un insieme di file .class ragguppati in una directory di nome) form.
LIBPATH: io ho definito anche una variabile di ambiente LIBPATH che punta alla directory delle librerie condivise. Quando scriviamo ad esempio un JavaBean che può essere utilizzato da più applicazioni invece di effettuarne il deployment per ogni applicazione lo mettiamo in un'area condivisa, questa è la directory
```
LIBPATH=$CATALINA_HOME/shared/lib/
```
Di volta in volta potremo includere le librerie condivise citando nella CLASSPATH il percorso LIBPATH/nome_package_condiviso.

Start/stop di Tomcat

Da Linux:
/etc/rc.d/tomcat start per l'avvio
/etc/rc.d/tomcat stop per l'arresto
Ho fatto riferimento ad una distribuzione Suse Linux. Occorre avere i privilegi di root sulla macchina.

Da Windows: Pannello di controllo, Strumenti di amministrazione, Servizi: il servizio da avviare/arrestare si chiama "Apache Tomcat 4.1". Anche qui occorre avere i privilegi di Administrator.
Oppure utilizzare i pulsanti di comando su Start -> Tutti i programmi -> Apache Tomcat 4.1 -> Start Tomcat (Stop Tomcat).

Si può avviare Tomcat anche dai pulsanti che vengono aggiunti dall'installatore nella barra degli strumenti o anche a mano da linea di comando, digitando:

%CATALINA_HOME%\bin\startup

cd %CATALINA_HOME%\bin
startup

Per verificare che il turro funzioni, puntate il Vostro browser su http://localhost:8080/ e buona fortuna!

N.B. la porta TCP di ascolto standard per Tomcat è la porta 8080. Sulla porta 8080 potete anche spegnere il vostro web server perché Tomcat fa tutto da sé. Se il numero di porta confligge con un altro server, potete cambiare la porta editando il file $CATALINA_HOME/conf/server.xml: cercate "8080" e sostituitelo con un altro numero di porta > 1024 che non sia occupato.

Per ulteriori problemi che si verificassero, per cui non parte Tomcat, fate riferimento ai documenti installati nella directory: $CATALINA_HOME/webapps/tomcat-docs

Deployment di una applicazione

Deployment per noi significherà installazione, anche se il significato più preciso è quello corrispondente in italiano al nostro "posa in opera".

Come detto, nella cartella $CATALINA_HOME/webapps/ vivono le nostre applicazioni web.

La struttura standard di una applicazione è:

la sottodirectory di webapps che contiene l'applicazione (sia magazzino) al cui interno esistono
una o più cartelle in cui smistare il codice JSP dell'applicazione: ad esempio una cartella sql potrebbe contenere tutte le istruzioni SQL da lanciare da JSP, o una cartella images potrebbe contenere tutti i file JPEG e GIF.
Una cartella (obbligatoria) di nome WEB-INF che contiene:
- una cartella classes che contiene i packages e i sorgenti (obbligatoria)
- una cartella lib che può contenere dei package generali che potrebbe essere utile ditribuire con questa applicazione (facoltativa)
- una cartella tlds che contiene i file XML di definizione delle librerie di tag (tld sta per Tag Library Definition). Le tag libraries sono uno strumento che in questo corso non impareremo ad usare ma sono molto utili per costruire i tag HTML da JSP fornendo una certa automazione ad esempio per costruire i tag select o costruire i condizionali Java if {} else {} o, ancora, eseguire query SQL. Questa cartella è facoltativa.
- Un file XML web.xml, il cosiddetto deployment descriptor che è utile quando si usano molte librerie standard per creare all'atto della installazione dell'applicazione in un sistema (deployment) la struttura dell'applicazione nel file system e descrivere le dipendenze dell'applicazione da altre librerie di classi.
  Generalmente, quando l'applicazione raggiunge un volume ragguardevole di file e di librerie, è utile automatizzare l'installazione. Per questo esiste un programma che si chiama ant che fa uso di questo file web.xml per decidere sia la struttura delle directory che le dipendenze dell'applicazione JSP dalle varie classi e dalle varie librerie, come anche le politiche di security sulle varie cartelle e i vari file (si può decidere chi può usare cosa nell'applicazione).
  In questo corso NON impareremo ad usare ant. Il file web.xml è facoltativo.

Come funziona Tomcat

JSP è un metodo EMBEDDED di programmare, ossia si immergono righe di codice di programmazione JAVA all'interno dell'HTML. Dal lato server però quello che succede è che viene compilata ed eseguita una applicazione Java equivalente al nostro script, ed essendo dal lato server prende il nome di servlet (server+applet). Tomcat in sostanza esegue il parsing della pagina JSP, sostituisce il codice HTML puro con dei print di codice cablato e concatena i pezzi di Java scritti tra i tag JSP <% ... %>.

Il risultato è appunto una servlet (.java) di cui possiamo vedere il codice nella directory

$CATALINA_HOME/work/Standalone/localhost/magazzino/jsp

al solito se magazzino è la nostra applicazione. Nella stessa directory c'è anche la servlet compilata (.class) che è quella che viene eseguita da Tomcat.

Ci possiamo rendere conto di questo fatto quando mandiamo in esecuzione uno script per la prima volta: la risposta del server sarà abbastanza lenta, in quanto la prima volta viene costruito il codice java e viene prodotto il file .class dal compilatore, e quindi viene caricata ed eseguita la servlet. Le volte successive invece verrà solo caricata ed eseguita la servlet .class (già pronta) e la risposta del server sarà notevolemente più rapida.

Reloading di una applicazione

E' una operazione che diviene necessaria, talvolta, soprattutto in fase di sviluppo, se usiamo i JavaBeans.

Se il nostro codice JSP contiene dei riferimenti a qualche classe Java, e noi apportiamo delle modifiche al codice di queste classi, dobbiamo, al momento della creazione delle servlet, dire al ClassLoader di riferirsi alla nuova versione del file .class. Per fare ciò abbiamo due alternative:

Riavviare Tomcat: questa scelta è infelice se più sviluppatori stanno usando Tomcat ma anche quando si sta lavorando da soli, ho notato che Windows XP è molto lento nel riavviare Tomcat.
Effettuare un reload: per lanciare questo comando è sufficiente scrivere nella barra degli indirizzi del browser:
```
http://localhost:8080/manager/reload?path=magazzino/
```
se magazzino, al solito, è la nostra applicazione. Questa operazione è tuttavia concessa solo all'utente Tomcat admin; questo è un utente predefinito che ha la possibilità di configurare molte cose di Tomcat; la password predefinita è admin, in ogni caso possiamo trovare tutti gli utenti definiti per Tomcat nel file $CATALINA_HOME/conf/tomcat-users.xml.
Altri comandi disponibili all'utente admin si trovano nella pagina http://localhost:8080/manager/.

<< Indice