Le applicazioni Web basate su architettura J2EE, per definizione, devono essere multipiattarforma.
Devono quindi poter girare su architetture hardware e software differenti a condizione che sulla piattaforma possa essere operativo un application server compatibile con le specifiche J2EE.
Nell’ottica di sviluppare applicazioni professionali, e quindi dotate di buone caratteristiche di qualità, è fondamentale effettuare dei test di integrazione anche su piattaforme differenti da quelle sulla quali viene effettuato lo sviluppo.
Nei laboratori, in genere, esistono postazioni di sviluppo con tecnologia windows, la realizzazione di un’applicazione web pertanto consente piccoli unit-test eseguiti in ambito locale su un Tomcat installato sulla stessa macchina sulla quale si esegue il processo di sviluppo del codice, cosa che deve comunque essere fatta, ma che non è sufficiente a garantire il funzionamento del componente in integrazione con altri elementi dell’applicazione.
Ecco quindi la necessità di utilizzare un ambiente di test, dove generalmente viene eseguito il test di integrazione di tutte le componenti dell’applicazione.
Un passo ulteriore, che denota la propensione alla produzione di codice di qualità più consistente, consiste nell’utilizzo di un ambiente di test parallelo su architettura differente.
È sempre bene, ad esempio, testare la stessa applicazione J2EE su ambienti differenti e quindi, in genere utilizzando un’istanza di Tomcat su una macchina Windows 2000 Server ed un’instanza di Tomcat su una macchina Linux.
Le carte si mescolano ancora meglio se obblighiamo istanze differenti dell’application server ad utilizzare istanze diverse di un eventuale database con nome, username e password differenti, in modo da testare il comportamento dell’applicazione in condizioni diverse e controllare che non ci siano quei refusi che di solito vengono fuori soltanto negli ambienti di produzione con grande disappunto del cliente finale.
Ecco quindi la necessità di utilizzare un sistema come Linux con un’installazione di Tomcat.
C’è da dire che per qualcuno “il sistema” è Linux e il sistema “alternativo” e Windows, ma cambiando l’ordine dei fattori il risultato non cambia, rimane l’esigenza di incrociare i test.
Per installare Tomcat su Linux è necessario prima di tutto scaricare l’ultima versione del pacchetto di installazione.
Le distribuzioni di Tomcat per Linux si trovano a questo indirizzo.
A noi interessa la 4.1.12 full in formato rpm, cioè quella che ha come nome di file:
tomcat4-4.1.12-full.2jpp.noarch.rpm raggiungibile direttamente da qui.
Per non scoprirlo dopo l’installazione, vi dico subito che per far partire il servizio è necessario anche il file che contiene le webapps con gli esempi e con l’applicazione di amministrazione.
Il file in questione si chiama tomcat4-webapps-4.1.12-full.2jpp.noarch.rpm e si può scaricare qui.
Come saprete per utilizzare Tomcat è necessario avere installato sulla propria macchina un J2SDK oppure un JRE della Sun.
Scarichiamo direttamente il J2SDK nella versione più recente 1.4.1.01, il file si chiama j2sdk-1_4_1_01-linux-i586-rpm.bin e si trova qui.
A questo punto sulla nostra fidata macchina Linux dovremmo avere questa situazione:
Installare il J2SDK
L’installazione del J2SDK prevede l’esecuzione del file binario, questa si ottiene con il comando:
./j2sdk-1_4_1_01-linux-i586-rpm.bin
/
Che si occupa, dopo averci chiesto di accettare la licenza SUN, di installare tutto il pacchetto nella posizione del file system:
A questo punto è necessario modificare il file di profilo degli utenti /etc/profile per aggiungere la variabile d’ambiente JAVA_HOME nella posizione dell’installazione. Questo si ottiene aggiungendo al file /etc/profile la seguente sezione:
JAVA_HOME=/usr/java/j2sdk1.4.1_01
export JAVA_HOME/
Inoltre ci sarà da aggiungere al PATH il percorso $JAVA_HOME/bin per rendere raggiungibili i tools di Sun da ogni punto del file system.
Installare Tomcat
Per installare Tomcat, visto che abbiamo scaricato i file di installazione in formato rpm, è necessario utilizzare l’apposita utility rpm.
In particolare il comando rpm -i tomcat4-4.1.12-full.2jpp.noarch.rpm provvede all’installazione completa di tutto l’application server, ma non esegue lo startup del servizio, infatti non funzionerebbe nulla senza prima aver installato anche il pacchetto relativo alle webapps.
Per installare quest’ultimo oggetto dobbiamo utilizzare il comando
rpm -i tomcat4-webapps-4.1.12-full.2jpp.noarch.rpm
Al termine della doppia esecuzione del tool rpm, ci troveremo nella seguente situazione.
In /var/tomcat4 avremo la seguente alberatura
come si vede dall’immagine in /etc/tomcat4 ci sono i file di configurazione, in /var/log/tomcat4 ci sono i log, in /var/cache/tomcat4/temp ci sono i file temporanei ed in /var/cache/tomcat4/work ci sono le servlet precompilate a partire dalla pagine JSP.
Per far partire il servizio, invece, è necessario andare in /etc/init.d e troveremo il servizio vero e proprio che può essere fatto partire attraverso il comando tomcat4 start
Seconda la filosofia Unix “no news, good news” (“nessuna nuova, buona nuova”) il sistema ci informa soltanto che ha utilizzato le variabili d’ambiente come da configurazione, non ci dice nient’altro.
Per verificare che lo start sia avvenuto correttamente è necessario utilizzare il browser, questo si può fare in locale con Mozilla
Ma la cosa migliore è sempre quella di provare da una postazione remota, ecco la prova fatta con Explorer su un sistema Microsoft.
Adesso avete, gratuitamente, un application server J2EE installato e funzionanente, non vi resta altro da fare che portare le vostre applicazioni nella directory webapps e vedere se funzionano.