No more maintained.
Now just a test in a lab.
JAVA Application Servers
Resin, Tomcat... Principi, Installazione, configurazione.
Storia delle Applicazioni Web
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Il linguaggio Java fu concepito inizialmente per essere utilizzato in piccoli dispositivi integrati. Inizialmente venne publicizzato come linguaggio per lo sviluppo di contenuto elaborato sul lato client sotto forma di Applet. Ora invece Java è riuscito a farsi riconoscere come linguaggio ideale per lo sviluppo di applicazioni lato server.
La capacità di Java di abbracciare diverse piattaforme si rivela particolrmante utile per le organizzazioni che dispongono di un insieme eterogeneo di Server che eseguono diverse varianti di sistemi operativi Unix e Windows (e sempre piu' anche Mac OS X).
La moderna concezione a oggetti e a memoria protetta di Java permette agli sviluppatori di ridurre i cicli di sviluppo per incrementare l'affidabilità del loro codice.
Oltre a questo, il supporto incorporato di Java per le API di rete e a livello di impresa consente di accedere ai dati gestiti di sistemi legacy come i mainframe, agevolando la transizione dai sistemi client/server più datati.
Le servlet Java sono componenti chiave dello sviluppo Java con un grado di portabilità, flessibilità e facilità d'uso finora sconosciuto.
Sebbene le servlet possano essere impiegate per estendere la fuzionalità di qulunque server con supporto Java, nella maggior parte dei casi esse vengono utilizzate per estendere i server Web, configurandosi come potenti ed efficienti sostituti degli script CGI.
Quando si utilizza una servlet per la creazione di contenuto dinamico per una pagina Web o per estendere in altro modo la funzionalità di un server Web, ciò che in effetti avviene è la creaziione di un'applicazione Web.
Mentre una pagina Web si limita a visualizzare un contenuto statico e permette all'utente di spostarsi al suo interno, un'applicazione Web offre agli utenti un'esperienza più interattiva.
Un'applicazione Web può essere una semplice funzione di ricerca con parola chiave in un archivio di documenti oppure un complesso sito di commercio elettronico.
Le applicazioni Web interessano sia Internet sia le Intranet ed Extranet aziendali, dove sono in grado di aumentare la produttività e cambiare il modo in cui società grandi e piccole gestiscono la loro attività commerciale.
Per comprendere la potenza delle servlet, dobbiamo però fare un passo indietro ed esaminare alcune delle altre soluzioni che è possibile adottare per creare applicazioni Web.
Common Gateway Interface
La Common Gateway Interface, nota comunemente come CGI, è stata una delle prime tecniche pratiche per la creazione di contenuto dinamico. Grazie a essa un server Web passa determinate richieste a un programma esterno, il cui output viene poi inviato al client al posto di un file statico. L'avvento della tecnologia CGI ha reso possibile l'implementazione di funzionalità nuove di ogni genere nelle pagine Web, tanto che essa è diventata rapidamente uno standard di fatto, implementato su tantissimi sever Web.
E' interessante osservare che la capacità dei programmi CGI di creare pagine Web dinamiche è un effetto collaterale dello scopo originale per il quale questa tecnica era stata concepita, ossia definire un metodo standard che consentisse a un server di informazioni di comunicare con le applicazioni esterne.
Questa origine spiega perchè il ciclo di vita di CGI è forse il peggiore che si possa immaginare.
Quando un server riceve una richiesta che accede a un programma CGI, deve creare un nuovo processo per eseguire il programma CGI e poi passare a quest'ultimo, tramite variabili di ambiente e standard input, tutte le informazioni che potrebbero essere necessarie per generare una risposta.
La creazione di un processo per tutte le richieste di questo tipo richiede tempo e impegna notevolmente le risorse del server, fattori che limitano il numero di richieste che un server può gestire contemporeanemente.
Anche se un programma CGI può essere scritto con quasi tutti i linguaggi oggi conosciuti, il linguaggio di programmazione Perl è diventata la scelta predominante.
Un altro problema spesso trascurato della tecnica CGI è che questo genere di programm non può interagire con il server Web o sfruttare le capacità di quest'ultimo una volta che inizia l'esecuzione in quanto essa ha luogo in un processo separato. Per esempio, uno script CGI non può scrivere sul file log del server.
FastCGI
Una società denominata Open Market ha sviluppato un'alternativa alla tecnologia CGI standard denominata FastCGI. Per molti aspetti FastCGI funziona come CGI, con l'importante differenza che la prima crea un singolo processo persistente per ogni programma FastCGI. Ciò elimina la necessita di creare un nuovo processo per ogni richiesta e aumenta considerevolmente la velocità di risposta alle richieste dei client.
Sebbene costituisca un passo in avanti, FastCGI presenta ancora un problema di proliferazione: esiste infatti almeno un processo per ogni programma FastCGI. Se un programma FastCGI deve gestire richieste concorrenti, ha bisogno di un pool di processi, uno per richiesta.
Se si considera che ciascun processo potrebbe esesguire un interprete Perl, questo metodo non riduce il carico sul sistema nella misura che si potrebbe sperare. Va detto comunque a favore di FastCGI che è una tecnica in grado di distribuire i suoi processi su più server.
Un altro problema di FastCGI è che non contribuisce in alcun modo a far si che il programma FastCGI interagisca in modo più stretto con il Web server. Infine,i programmi FastCGI sono portabili solo nella misura in cui lo è il linguaggio nel quale sono scritti. Per maggiori informazioni su FastCGI, si veda il sito http://www.fastcgi.con
PerlEx
Perl,sviluppato da ActiveState, migliora le prestazioni degli script CGI scritti in Perl che vengono eseguiti su server Web Windows (Internet Information Server di Microsoft, WebSite Professional di O'Reilly e Enterprise Server di iPlanet). Esso presenta vantaggi e svantaggi simili a quelli di FastCGI.
Per maggiori informazioni su PerlEx, si veda il sito http://www.activestate.com/plex.
mod_perl
Se si utilizza il Web Server Apache, per migliorare la prestazione della tecnologia CGI si puo ricorrere a mod_perl, un modulo per server Apache che incorpora una copia dell'interprete Perl nell'eseguibile di Apache, offrendo un accesso completo alla funzionalità Perl all'interno di Apache. Gli script CGI vengono precompilati da server ed eseguiti senza operazioni di forking, consentendo pertanto una maggiore velocità ed efficienza nelle operazioni.
Lo svantaggio è che l'applicazione è compatibile solo con il server Apache.
Per maggiori informazioni su mod_perl, si veda il sito http://perl.apache.org.
API di estensione del server
Sono diverse le società che hanno creato delle API di estensione del server proprietarie per i loro server Web. Per esempio,iPlanet/Netscape offre un'API interna chiamata WAI (inizialmente NSAPI), mentre Microsoft fornisce ISAPI. Con una di queste API è possibile scivere estensioni del server che ne potenziano o ne cambiano le funzionalità di base, permettendogli di gestire operazioni un tempo relegate a programmi CGI esterni. Le estensioni del server esistono all'interno del processo principale di un Server Web. Dato che le API specifiche del server usano codice C o C++ collegato tramite un linker, le estensioni del server possono offrire un'esecuzione molto rapida e sfruttare appieno le risorse del sistema. Le estensioni del server sono tuttavia ben lungi dall'essere una soluzioni perfetta. Oltre a presentare difficoltà di sviluppo e manutenzione, pongono seri rischi di sicurezza e affidabilità: un'estensione in crash può interrompere il funzionamento dell'intero server, mentre una maligna potrebbe sottrarre informazioni, come le password e i numeri di carta di credito degli utenti di un sito. Inoltre, le estensioni del server proprietarie sono ovviamente legate in modo inscindibile alle API del server per la quale sono state scritte e spesso anche a un particolare sistema operativo.
Server-Side JavaScript
Anche iPlanet/Netscape offre una tecnica per lo scripting sul lato server chiamata SSJS (Server-Side JavaScript). Come ASP, SSJS permette di incorporare frammenti di codice nelle pagine HTML per generare un contenuto Web dinamico. La differenza è che SSJS utilizza JavaScript come linguaggio di scipting. Con SSJS le pagine Web vengono precompilate per migliorare le prestazioni. Il supporto per Server-Side JavaScript e' disponibile solo con i server iPlanet/Netscape.
Active Server Pages
Microsoft ha messo a punto una tecnica per la generazione di contenuto Web dinamico chiamata ASP (Active Server Pages), per mezzo della quale una pagina HTML sul server Web può contenere frammenti di codice incorporato (in genere VBScript o JScript, anche se è possibile utilizzare quasi tutti i linguaggi). Tale codice viene letto ed eseguito dal server Web prima che questo invii la pagina al client, ASP è ottimizzato per la gnerazione di piccole parti di contenuto dimamico, sfruttando i componenti COM per compiere il lavoro pesante.
Il supporto per ASP è integrato in MIcrosoft Internet Information Server versione 3.0 e successive, disponibile gratuitamente all'indirizzo http://www.microsoft.com/iis.
Il supporto per altri server Web è disponibile come prodotto commerciale presso Chili!Soft, http://www.chilisoft.com. E' importante tenere presente che le pagine ASP in esecuzione su una piattaforma differente da Windows potrebbero incontrare difficoltà nello svolgimento di operazioni avanzate senza la libreria COM di Windows.
PHP
PHP, che significa "PHP: Hypertext Preprocessor", è un linguaggio di scripting general-purpose Open Source molto utilizzato, è specialmente indicato per lo sviluppo Web e può essere integrato nell'HTML. La sua sintassi è basata su quella di C, Java e Perl, ed è molto semplice da imparare. L'obiettivo principale del linguaggio è quello di permettere agli sviluppatori web di scrivere velocemente pagine web dinamiche, ma con PHP si possono fare molte altre cose.
Tra i vantaggi di PHP sicuramente sta nel fatto che è completamente open source, quindi molto usato e conosciuto. Inoltre è integrabile in numerosi server Web.
Tra i contro è poco orientato agli oggetti, le librerie standard hanno aspetto procedurale e caratteristiche importanti sono disponibili soltanto nelle recenti versioni.
Il manuale e maggiori informazioni dono disponibili sul sito http://www.php.net/.
JavaServer Pages
JSP(JavaSeverPages) è un'alternativa ad ASP basata su Java, inventata e standardizzata da Sun. JSP utilizza una sintassi simile a quella di ASP, con la differenza che il linguaggio di scripting è Java.
A differenza di ASP, JSP è uno standard aperto implementato da moltissimi produttori su tutte le piattaforme. JSP è strettamente legato alle servlet, perchè una pagina JSP viene trasformata in un servlet come parte della sua esecuzione. Per maggiori informazioni su JSP, si veda il sito http://java.sun.com/products/jsp.
Servlet Java
Una servlet è un'estensione del server generica, una classe Java che può essere caricata in modo dinamico per espandere la funzionalità di un server. Le servlet sono utilizzate comunemente con i server Web, dove possono prendere il posto degli script CGI. Una servlet è simile a un'estensione del server proprietaria, tranne per il fatto che la sua esecuzione ha luogo all'interno di una JVM(Java Virtual Machine) sul server e pertanto è sicura e portabile.
Le servlet operano unicamente all'interno del dominio del server. A differenza delle applet, non richiedono che il browser Web offra il supporto Java.
A differenza di CGI e FastCGI, che devono usare più processi per gestire programmi e/o richieste separati, tutte le servlet possono essere gestite da thread separati all'interno dello stesso processo o da thread a più processi diffusi su diversi server backend. Ciò significa che le servlet sono sia efficienti sia scalabili. Instaurando una comunicazione bidirezionale con il server Web, le servlet possono interagire in modo molto stretto con il server per fare ciò che non è possibile con gli script CGI.
Un altro vantaggio delle servlet è la loro portabilità, relativa sia ai sistemi operativi, caratteristica già presente in Java, sia ai server Web.
Lo svantaggio maggiore è una certa pesantezza dovuta alla necessità di avere in memoria un intera Java Virtual Machine al cui interno devono andare in esecuzione le servlet.
Supporto per le servlet
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Come il linguaggio Java stesso, le servlet sono state progettate per ottenere la massima portabilità e sono accettate da tutte le piattaforme che offrono un supporto Java e che funzionano con tutti i principali server Web.
Le servlet Java, stando alla definizione offerta dalla divisione Java Software di Sun Microsystems, sono un Optional Package per java. Ciò significa che le servlet sono ufficialmente riconosciute da Sun e fanno parte del linguaggio Java, anche se non nel nucleo fondamentale dell'API Java; esse, invece, sono comprese nella piattaforma J2EE.
Per agevolare il lavoro di sviluppo delle servlet, Sun ha reso disponibili le classi delle API separatemente da qualunque motore Web. I pacchetti javax.servlet e javax.servlet.http sono gli elementi costitutivi di questa Servlet API. L'ultima versione di queste classi può essere prelevata dalla pagina http://java.sun.com/products/servlet/download.html.
Tutti i server Web che offrono supporto per le servlet devono utilizzare classi internamente (anche se potrebbero utilizzare un'implementazione alternativa), pertanto questi file JAR si trovano in genere anche in qualche punto della distribuzione del proprio server Web nel caso in cui offra supporto per le servlet.
Oltre alle classi delle servlet, è necessario un esecutore di servlet, tecnicamente chiamato servlet container o anche servlet engine, in modo da poter verificare e mettere in opera le proprie servlet.
La scelta del servlet container dipende in parte dal server o dai server Web in esecuzione.
Esistono tre generi di Servlet container: autonomi, aggiuntivi e incorporabili
Sevlet container autonomi
Un servlet container autonomo è un server che include un supporto nativo per le servlet. Questo container ha il vantaggio di far funzionare ogni cosa fin dal principio, presentando però lo svantaggio che è necessario attendere una nuova release del server Web per ottenere il supporto per servlet più aggiornate. Un altro svantaggio è che i produttori del server in genere supportano solo la JVM da essi fornita.
Tra i server Web che offrono supporto autonomo ci sono quelli inclusi nell'elenco che segue:
- Tomcat Server di Apache, l'implementazione di riferimento ufficiale per il modo in cui il servlet container deve fornire supporto per le servlet. E' scritto interamente in Java ed è disponibile gratuitamente con licenza open source. Questo server può operare in modo autonomo o come come componente aggiuntivo, offrendo il supporto per i servlet ad Apache o altri server. Può persino essere impiegato come container incorporato.
Insieme a Tomcat, Apache sviluppa l'implementazione standard dei pacchetti javax.servlet e javax.servlet.http.
Si veda il sitohttp://jakarta.apache.org.
- iPlanet (Netscape) Web Server Enterprise Edition forse il server Web più famoso tra quelli commerciali che offrono supporto servlet integrato. Maggiori dettagli al sito http://www.iplanet.com
- WebSite Professional di O'Reilly, con funzionalità simili a iPlanet Enterprise Server ma un prezzo inferiore. http://website.oreilly.com.
- Zeus Web Server, un server Web che alcuni considerano il più veloce tra quelli disponibili. http://www.zeus.co.uk.
- Resin di Caucho, un container open source che vanta ottime prestazioni. Può funzionare in modalità autonoma o come componente aggiuntiva per molti server. http://www.caucho.com.
- LiteWebServer di Gefion Software, un piccolo servlet container (poco piu' di 100k) concepito per essere impiegato laddove le dimensioni sono importanti, come l'inclusione nelle versioni dimostrative delle applicazioni.http://www.gefionsoftware.com/LiteWebserver
- Jigsaw Server del World Wide Web Consortium, open source e scritto interamente in java. http://www.w3.org/Jigsaw.
- Java Web Server di Sun, il server che ha dato inizio a tutto. Questo server è stato il primo ad implementare le servlet e ha agito come effettiva implementazione di riferimento per le Servlet API 2.0. E' scritto interamente in Java (tranne due librerie di codice nativo che ne migliorano le funzionalità ma non necessarie). Sun ha sospeso lo sviluppo del server, preferendo concentrarsi sui pacchetti iPlanet/Netscape come parte dell'alleanza Sun-Netscape. http://java.sun.com/products.
I server di applicazioni sono un'area di svilupppo in crescita. Essi offrono supporto sul lato server per lo sviluppo di applicazioni a livello di impresa. La maggior parte delle applicazioni Java supportando le servlet e tutto il resto della specifica J2EE(Java 2 Enterprise Edition). Tra questi server troviamo quelli elencati di seguito.
- WebLogic Application Server di BEA System, uno dei primi e più famosi application server basati su Java. http://www.beasys.com/products/weblogic.
- Orion Application Server, sofisticato ma dal prezzo relativamente contenuto, scritto interamente in Java. http://www.orionserver.com.
- Enhydra Application Server, open source prodotto da Lutris. http://www.enydra.com.
- Borland Application Server 4, che rivolge particolare attenzione a CORBA. http://www.borland.com/oppserver.
- WebSphere Application Server di IBM, di alto profilo basato in parte sul codice di Apache. http://www.ibm.com/software/webservers.
- Application Server di Oracle, un server concepito per l'integrazione con i database Oracle. http://www.oracle.com/appserver.
- iPlanet Application Server, il fratello maggiore compatibile J2EE di iPlanet Web Server Enterprise Edition. htpp://www.iplanet.com/products/infrastructure/app_servers/nas.
- GemStone/J Application Server, un server Java di una società nota in precedenza per il suo server Smalltalk. http://www.gemstone.com/products/j.
- JRun Server di Allaire, un semplice servlet container cresciuto fino a diventare un container avanzato che offre molte tecnologie J2EE, tra cui EJB, JTA e JMS. http://www.allaire.com/products/jrun.
- Silverstream Application Server, un server completamente compatibile con J2EE, anch'esso concepito come servlet container. http://www.silverstream.com.
Servlet container aggiuntivi
Un servlet container aggiuntivo funziona come plug-in per un server: aggiunge il supporto per servlet a un server che in origine non è stato concepito per esse o a u server con un'implementazione servlet di basso profilo o obsoleta.
Sono stati scritti servlet container aggiuntivi per molti server, tra cui Apache, iPlanet, FasTrack Server e Enterprise Server, Microsoft Internet Information Server e Personal Web Server, O'Reilly WebSite, Lotus Domino Go Webserver, StarNine WebSTAR e AppleShare IP della Apple. Alcuni tra questi sono elencati di seguito.
- ServletExec di New Atlanta, un plug-in concepito per offrire supporto per i servlet a tutti i server Web più diffusi per tutti i principali sistemi operativi. Include un debugger gratuito. http://www.servletexec.com.
- JRun di Allaire disponibile come plug-in per offrire supporto per servlet a tutti i server Web più diffusi per tutti i principali sistemi operativi. http://www.allaire.com/products/jrun.
- Il modulo JServ del progetto Java-Apache, un servlet container open source disponibile gratuitamente che offre supporto per i servlet al diffussisimo server Apache. Lo sviluppo di JServ è stato completato e Tomcat Server ha sostituito JServ. http://www.java.apache.org.
Servlet container incorporabili
Un container incorporabile è in genere una piattaforma leggera per il deployment delle servlet che può essere incorporata in un'altra applicazione. A questo punto l'applicazione diventa il server vero e proprio.
Tra i servlet container incorporabili vi sono quelli elencati di seguito.
- Tomcat Server di Apache, sebbene in genere esso venga utilizzato come server autonomo o aggiuntivo, esso può essere incorporato in un'altra applicazione se necessario. Open source.
- Nexus Web Server, un esecutore di servlet disponibile gratuitamente che implenta la maggior parte delle Servlet API e che può essere facilmente incorporato nelle applicazioni Java. http://www.uk.hpl.hp.com/people/ak/java/nexus.
La Servlet API
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Si accenna in breve ad alcune istruzioni pratiche per scrivere ed eseguire semplici servlet. E' necessario possedere una conoscenza di base del protocollo HTTP oltre ad avere un base del linguaggio Java.
Le servlet usano le classi e interfacce provenienti da due pacchetti: javax.servlet e javax.servlet.http
Il primo contiene le classi e le interfacce necessarie per supportare servlet generiche, indipendenti dal protocollo. Queste classi vengono estese dalle classi presenti nel pachetto javax.servlet.http per aggiungere funzionalità specifiche del protocollo HTTP. Il nome del pacchetto di livello superiore è javax invece del piu' comune java, per indicare che le Servlet API sono un pacchetto opzionale. Tutte le servlet devono implementare l'interfaccia javax.servlet.Servlet.
La maggior parte delle servlet implenta questa questa interfaccia estendendo una di quests classi speciali: javax.servlet.GenericServlet o javax.servlet.http.HttpServlet.
Una servlet indipendente dal protocollo deve trasformare in sottoclasse GenericServlet, mentre una servlet HTTP deve trasformare in sottoclasse HttpServlet, che è essa una sottoclasse di GenericServlet a cui sono state aggiunte funzionalità specifiche di HTTP.
A differenza di un programma Java e come un'applet, una servlet non possiede un metodo main(). Certi metodi di una servlet, invece, vengono richiamati dal server nel processo della gestione delle richieste: ogni volta che il server recapita una richiesta a un servlet, invoca il metodo service() di quest'ultima.
Una servlet generica deve ridefinire il suo metodo service() per gestire le richieste in modo appropriato. Questo metodo accetta due parametri: un oggetto richiesta e un oggetto risposta.
Il primo informa la servlet sulla richiesta, mentre il secondo viene impiegato per restituire una risposta.
Al contrario, una servlet HTTP in genere non ridefinisce il metodo service(), bensì doGet() per gestire le richieste GET e doPost() per quelle POST.
Una servlet HTTP può ridefinire uno di questi metodi o entrambi, in relazione al tipo di richiesta che deve gestire. Il metodo service() di HttpServlet gestisce l'impostazione e il recapito di tutti i metodi doXXX(), che è il motivo per cui in genere non dev'essere ridefinito.
La parte restante dei pacchetti javax.servlet e javax.servlet.http è costituita in gran parte da classi di supporto.
Installazione e configurazione di Tomcat
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Tomcat è parte di Jakarta, progetto open source rilasciato sotto Apache Software License, che sviluppa e distribuisce soluzioni per la piattaforma Java. Tomcat è un servlet container usato per l'implementazione della tecnologia javaServlet e javaServerPages.
Le specifiche delle JavaServlet e JavaServerPages sono sviluppate dalla Sun.
In base alla versione di Tomcat si hanno le seguenti specifiche:
- Servlet/JSP Spec Tomcat versione
2.4 / 2.0 5.0.x (in fase di sviluppo )
2.3 / 1.2 4.1.12
2.2 / 1.1 3.3.1
Vediamo la procedura di installazione di Tomcat, usando direttamente i binari distribuiti sul sito ufficiale.
1. Installazione JDK
Il primo passo è il download e l'installazione della piattaforma Java (SDK 1.3 o successive).
JDK 1.3: http://java.sun.com/j2se/1.3/
JDK 1.4: http://java.sun.com/j2se/1.4/download.html
Si possono scaricare direttamente in formato binario rpm, che va semplicemente eseguito. Es:
./j2sdk-1_4_0_03-linux-i586-rpm.bin
Questo pacchetto specifico mette i suoi file in /usr/java/j2sdk1.4.0_01/
2. Download di Apache Tomcat Server
Dal sito ufficiale http://jakarta.apache.org/ si può scaricare Tomcat si in formato binario, precompilato per il proprio sistema, che come sorgenti, da compilare a mano.
Nel nostro caso si sono scaricati e scompattatati i binari di Tomcat 4.0.6 in formato tar.gz:
tar -zxvf jakarta-tomcat-4.0.6.tar.gz
Viene creata una directory con varie sottodirectory. Fra queste si segnala la subdir conf dove risiedono tutti i file di configurazione (in formato XML) e bin dove si sono alcuni script e binari, tra cui quelli necessari per avviare e stoppare il server.
3. Impostazioni custom
Può aver senso, a questo punto, impostare alcuni parametri custom:
- Abilitazione l'ambiente di ROOT
Per default le applicazioni Web sono già abilitate in Tomcat 3, Tomcat 4.0.1-4.0.3, e alcune versioni di Tomcat 4.1. Ma in Tomcat 4.1.12 esse sono disabilitate per default. Per abilitarle, si deve scommentare la seguente linea nel file in install_dir/conf/server.xml:
<Context path="" docBase="ROOT" debug="0"/>
- Abilitazione dell'invoker delle servlet
In Tomcat 4.1.12, l'invoker è stato disabilitato per default, questo impedisce l'esecuzione di applet esterne che non siano espressamente mappate nel file di configurazione. Per abilitare l'invoker delle servlet, togliere il commento ai seguenti elementi di servlet-mapping in install_dir/conf/web.xml:
<servlet-mapping>
<servlet-name>invoker </servlet-name>
<url-pattern>/servlet/* </url-pattern>
<servlet-mapping>
- Modifica della porta in LISTENING
Per cambiare la porta su cui ascolta il server, editare install_dir/conf/server.xml e cambiare gli attributi della porta Connector element da 8080 alla porta che si desidera (es: 80).
<Connector
className="org.apache.catalina.connector.http.HttpConnector"
port="80" .../>
- Attivazione del Servlet Reloading
Per attivare il servlet reloading, editare install_dir/conf/server.xml e cercare il seguente commento:
< Define properties for each web application. This is only needed
if you want to set non-default properties, or have web application
document roots in places other than the virtual host's appBase
directory. >
Inserire quindi seguente linea:
<DefaultContext reloadable="true"/>
Assicurarsi di fare una copia di backup server.xml prima di fare queste modifiche.
4. Impostazione delle variabili d'ambiente JAVA_HOME e JAVA_CATALINA
Prima di avviare Tomcat vanno impostate alcune variabili d'ambiente:
JAVA_HOME, dove è collocato il JDK e JAVA_CATALINA dove è collocato Tomcat. Per esempio:
export JAVA_HOME=/usr/java/j2sdk1.4.0_01/
export JAVA_CATALINA=/home/web/jakarta-tomcat-4.0.6/
5. Avvio e test del Server
Eseguire install_dir/bin/startup.sh (su Unix/Linux) per avviare Tomcat.
Per testare se funziona aprire un browser locale e andare all' URL http://localhost:8080/ (si presumo che non si sia modificata la porta di default 8080)
Per fermare il Server: install_dir/bin/shutdown.sh.
Utilizzare servlet su Tomcat
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Il tipo più semplice di servlet Http genera una pagina HTML completa; tale servlet ha accesso alle stesse informazioni in genere inviate a uno script CGI e a qualcosa in più. Una servlet che genera una pagina HTML può essere utilizzata per tutte le attività per le quali attualmente si ricorre a CGI, come l'elaborazione dei moduli HTML, la produzione di report a partire da un database, l'accettazione di ordini, la verifica di identità e così via.
Scrivere Hello World
Il programma più semplice del mondo, scritto in Java presenta una complessità apparente che si spiega con la struttura ad oggetti del linguaggio.
Questa servlet, HelloServlet.java, si limita a scrivere "Hello World" ogni volta che un utente accede a essa tramite un browser Web:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Very simplistic servlet that generates plain text.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}
Esecuzione di Hello World
Utilizzando il server Apache Tomcat, si deve collocare il codice sorgente della servlet nella directory server_root/webapps/ROOT/WEB-INFO/classes (dove server_root è la directory in cui e' installato il proprio server).
Se la directoy classes non c'è bisogna crearla.
Una volta collocato il codice nella posizione corretta bisogna compilarlo, con javac HelloServlet.java (oppure al proprio ambiente grafico preferito per lo sviluppo java).
E' importante accertarsi di avere, nel proprio CLASSPATH, entrambi i pacchetti javax.servlet e javax.servlet.http.
Con il server Tomcat è sufficiente includere server_root/lib/servlet.jar nel proprio classpath altrimenti ci si imbatte in un messaggio di errore che dice qualcosa di simile a Package javax.servletnot found in import.
Ora che la prima servlet è stata compilata non rimane altro che avviare il server e accedere a essa.
E' possibile inserire questo URL nel proprio browser preferito:http://localhost:8080/servlet/HelloServlet
Apache + Tomcat + JK Connector
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
L'application server Tomcat può essere utilizzato sia in modalità stand-alone che insieme ad Apache, il quale funge da front-end pubblico per l'erogazione delle pagine e del servizio, ma che si avvale in background di Tomcat per quanto concerne l'esecuzione di servlet e pagine JSP.
La comunicazione tramite web server e servlet container viene gestita dal connector JK di cui parleremo successivamente.
I requirement per ottenere un ambiente come quello che vogliamo creare sono i seguenti:
- Apache 2.0.x
- Tomcat 4.1.x
- Tomcat Web Server Connectors JK 1.2
- JDK 1.4.x
INSTALLAZIONE JVM
Prima di tutto bisogna installare la Java Virtual Machine sulla propria Linux Box, per fare ciò bisogna scaricare da http://java.sun.com/j2se/1.4.2/download.html il JDK SE 1.4.x in formato bin per Linux.
Una volta scaricato il pacchetto binario lo si installa in /usr/local (questa è solo una mia preferenza personale).
Successivamente si deve impostare la variabile di ambiente $JAVA_HOME. Il comando è:
JAVA_HOME=/usr/local/j2sdk1.4.2_04
export JAVA_HOME
Fatto questo si può testare il corretto funzionamento eseguendo:
echo $JAVA_HOME
Il risultato ottenuto dovrebbe essere:
/usr/local//usr/local/j2sdk1.4.2_04
INSTALLAZIONE APACHE
A questo punto dobbiamo procedere con la compilazione del server web Apache, nel nostro caso tramite sorgenti di Apache 2.0.49.
cp -p httpd-2.0.49.tar.gz /usr/local/src/
cd /usr/local/src
tar xvzf httpd-2.0.49.tar.gz
Ora possiamo procedere alla compilazione di Apache:
cd /usr/local/src/httpd-2.0.49
./configure --prefix=/usr/local/apache --enable-ssl --enable-so ; make ; make install
INSTALLAZIONE DI TOMCAT
Prima di tutto dobbiamo creare l'utente tomcat in modo tale da far girare l'application server senza i permessi di root (pericolosissimo per la sicurezza del sistema).
groupadd tomcat
useradd -g tomcat -c "Tomcat User" -d /usr/local/tomcat tomcat
passwd tomcat
La password è a vostra discrezione...
Notare che viene scelta come home directory dell'utente /usr/local/tomcat
Dopo aver scaricato Tomcat 4.1.30 in formato binario possiamo procedere all'installazione:
cp -p tomcat-4.1.30.tar.gz /usr/local/
cd /usr/local
tar xvzf tomcat-4.1.30.tar.gz
Verrà creata la cartella /usr/local/jakarta-tomcat-4.1.30 contenente i binary dell'application server Tomcat.
Per una gestione più snella e semplice andiamo ad applicare un link simbolico:
ln -s /usr/local/jakarta-tomcat-4.1.30 /usr/local/tomcat
Fatto questo dobbiamo sistemare i permessi sulla cartella e sul link simbolico, ovvero assegnare come owner della cartella e dei files l'utente tomcat, se non lo facessimo l'utente tomcat non avrebbe la possibilità di far partire il server.
chown tomcat:tomcat /usr/local/tomcat
chown -R tomcat:tomcat /usr/local/jakarta-tomcat-4.1.30
Ora bisogna settare come per $JAVA_HOME la variabile d'ambiente $CATALINA_HOME che non è altro che il path a tomcat.
CATALINA_HOME=/usr/local/tomcat
export CATALINA_HOME
Ora possiamo far partire il server tomcat, ma solo dopo aver settato la variabile d'ambiente $JAVA_HOME anche per l'utente tomcat.
Facciamo quindi partire il servizio con:
su - tomcat -c /usr/local/tomcat/bin/startup.sh
Testiamo il funzionamento di tomcat con http://localhost:8080 (la porta 8080 è il default dell'application server).
In questo momento tomcat sta funzionando da web server stand-alone e da application server.
Ovviamente essendo il nostro obiettivo quello di avere Apache che fornisca l'interfaccia web e Tomcat che funga da servlet container.
Per fare ciò dobbiamo installare il connector JK per Apache e Tomcat.
Prima di tutto però spegnamo tomcat:
su - tomcat -c /usr/local/tomcat/bin/shutdown.sh
Fate attenzione a scaricare il connector JK 1.2 perchè la versione 2 è differente.
Scompattiamo il connector in /usr/local/src
cd /usr/local/src
tar xvzf jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz
Ora configuriamo la variabile $CONNECTOR_HOME con la cartella creata dallo scompattamento del tar.gz
CONNECTOR_HOME=/usr/local/src/jakarta-tomcat-connectors-jk-1.2.5-src
export CONNECTOR_HOME
Configuriamo e compiliamo ora il connector:
cd CONNECTOR_HOME/jk/native
./buildconf.sh
./configure --with-apxs=/usr/local/apache/bin/apxs
make
make install
Questi comandi compileranno mod_jk.so e lo copieranno in /usr/local/apache/modules.
CONFIGURIAMO APACHE E TOMCAT PER LAVORARE INSIEME
Andiamo ad editare il file server.xml di Tomcat e aggiungiamo questa riga dopo server
Listener className="org.apache.ajp.tomcat4.config.ApacheConfig" modJk="/usr/local/apache/modules/mod_jk.so" /
e dubito dopo la parte dell'host questa riga:
Listener className="org.apache.ajp.tomcat4.config.ApacheConfig" append="true" forwardAll="false" modJk="/usr/local/apache/modules/mod_jk.so" /
Infine aggiungiamo il modulo creato dal connector alla configurazione di Apache (httpd.conf) al termine del file di configurazione:
Include /usr/local/tomcat/conf/auto/mod_jk.conf
Ora creiamo in CATALINA_HOME/conf/jk un file di nome workers.properties
cd $CATALINA_HOME/conf
mkdir jk
chown tomcat:tomcat jk
cd jk
vi workers.properties
Il file sarà composto da queste linee:
worker.list=ajp13
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
Gli diamo i permessi corretti:
chown tomcat:tomcat workers.properties
A questo punto facciamo partire Apache ed il gioco è fatto.
Testiamo con: http://localhost/examples e se vengono processati i files java il lavoro è terminato.