Présentation des servlets et des JavaServer Pages

1
Présentation des servlets
et des JavaServer Pages
Au sommaire de ce chapitre
✔ Qu’est-ce qu’un servlet
✔ Quand et pourquoi peut-on utiliser des servlets
✔ Que sont les JavaServer Pages
✔ Quand et pourquoi peut-on utiliser des JSP
✔ Se procurer les logiciels de servlets et de JSP
✔ Installation et configuration des logiciels
Ce chapitre constitue une présentation rapide des servlets et des JavaServer
Pages (JSP), mettant en évidence les principaux avantages de ces deux techniques. Il montre ensuite comment obtenir et configurer les logiciels nécessaires à
l’écriture de servlets et au développement de documents JSP.
Servlets
Les servlets représentent l’alternative de la technologie Java à la programmation
avec CGI (Common Gateway Interface). Il s’agit de programmes exécutés sur un
serveur Web, qui servent de couche intermédiaire entre une requête provenant
14
Partie I
Servlets
d’un navigateur Web et un autre client HTTP, comme des bases de données ou
des applications du serveur HTTP. Leur tâche est de :
1. Lire toutes les données envoyées par l’utilisateur. Ces données sont typiquement saisies dans un formulaire sur une page Web, mais elles peuvent également
provenir d’une applet Java ou d’un programme client HTTP particulier.
2. Chercher d’autres informations sur la requête, à l’intérieur de cette
requête HTTP. Ces informations contiennent des détails sur les capacités du
navigateur, sur les cookies, sur le nom de l’hôte du programme envoyant la
requête, etc.
3. Générer les résultats. Ce processus peut nécessiter une communication avec
la base de données, en exécutant un appel RMI ou CORBA, ou en invoquant
une ancienne application, ou encore en calculant directement la réponse.
4. Formater le résultat dans un document. Dans la plupart des cas, cela implique l’incorporation des informations dans une page HTML.
5. Définir les paramètres de la réponse HTTP appropriés. Cela signifie qu’il
faut indiquer au navigateur le type de document renvoyé (c’est-à-dire HTML),
définir les cookies, mémoriser les paramètres, ainsi que d’autres tâches.
6. Renvoyer le document au client. Ce document peut être envoyé au format
texte (HTML), au format binaire (comme pour des images GIF), ou même
dans un format compressé comme gzip, qui est en fait une couche venant
recouvrir un autre format sous-jacent.
Certaines requêtes de clients peuvent être satisfaites en renvoyant des documents
préconstruits. Ce type de requête est géré par le serveur sans invoquer de servlets.
Cependant, dans un certain nombre de cas, un résultat statique n’est pas suffisant,
et il faudra alors générer une page particulière pour chaque requête. Il existe
plusieurs raisons expliquant la nécessité de construire des pages en temps réel :
m
m
La page Web est fondée sur des données envoyées par l’utilisateur. Par
exemple, les pages de résultats des moteurs de recherche et des pages de
confirmation de commande dans des magasins en ligne sont spécifiques à des
requêtes particulières d’utilisateurs.
La page Web est calculée à partir d’informations qui sont fréquemment
modifiées. Par exemple, un bulletin météo ou une page résumant les dernières
Chapitre 1
Présentation des servlets et des JavaServer Pages
15
nouvelles quotidiennes peut construire la page de manière dynamique, éventuellement en renvoyant une page déjà construite si elle est toujours valable.
m
La page Web se sert d’informations provenant de bases de données appartenant à des entreprises ou à d’autres sources situées au niveau d’un
serveur. Par exemple, un site de commerce électronique peut utiliser un servlet
pour construire une page Web qui établit la liste des prix et la disponibilité de
chaque article en vente.
En principe, les servlets ne sont pas restreints au Web ou à des serveurs d’applications qui gèrent des requêtes HTTP. Ils peuvent également être utilisés par
d’autres types de serveurs. Ainsi, les servlets peuvent être intégrés dans des
serveurs mail ou FTP, afin d’en accroître les capacités. Cependant, dans la pratique, cette utilisation des servlets n’est pas très courante, et nous nous contenterons d’aborder les servlets HTTP.
Avantages des servlets par rapport aux CGI "traditionnels"
Les servlets Java sont plus efficaces, plus simples à utiliser, plus puissants, plus
portables, plus sûrs, et moins chers que les CGI traditionnels et que plusieurs
autres technologies comparables aux CGI.
Efficacité
Avec un CGI traditionnel, un nouveau processus est exécuté pour chaque requête
HTTP. Si le programme CGI est assez grand, son chargement peut nécessiter
plus de temps que son exécution. Avec les servlets, la machine virtuelle Java est
exécutée en permanence et traite chaque requête grâce à un thread Java plus
simple, et non selon un processus complexe du système d’exploitation. De la
même manière, avec des CGI traditionnels, s’il existe n requêtes simultanées
demandant le même programme CGI, le code de ce programme sera chargé n fois
dans la mémoire. En revanche, avec des servlets, il y aurait uniquement n threads
et une seule copie de la classe du servlet. Enfin, lorsqu’un programme CGI a fini
de traiter une requête, ce programme se termine. Cela complexifie de manière
significative les calculs de mise en mémoire, la conservation d’une connexion
ouverte vers une base de données ainsi que d’autres optimisations fondées sur les
données persistantes. Cependant, comme les servlets restent en mémoire même
16
Partie I
Servlets
après le traitement d’une requête, ils peuvent facilement enregistrer des données
complexes entre deux requêtes.
Simplicité
Les servlets disposent d’une infrastructure complète pour analyser et décoder
automatiquement les données d’un formulaire HTML, pour lire et définir des entêtes HTTP, gérer les cookies, conserver une trace des sessions, ainsi que pour
bien d’autres outils de haut niveau. De plus, vous connaissez déjà le langage de
programmation Java. Pourquoi apprendre aussi le langage Perl ? Vous savez déjà
que la technologie Java produit du code plus fiable, dont la maintenance est plus
simple qu’avec le C++. Pourquoi en revenir à une programmation en C++ au
niveau du serveur ?
Puissance
Les servlets disposent de plusieurs facultés qui seraient difficiles, voire impossibles à implémenter avec des CGI classiques. Les servlets peuvent communiquer
directement avec le serveur Web, ce qui est impossible pour des CGI classiques,
du moins sans avoir recours à une API spécifique au serveur. Par exemple, la
communication avec le serveur Web simplifie la traduction d’URL relatives en
chemins complets. Plusieurs servlets peuvent également partager des données, ce
qui permet de réunir facilement plusieurs connexions de bases de données et
d’implémenter d’autres types d’optimisations fondées sur le partage de ressources. Les servlets peuvent aussi conserver des informations d’une requête à
l’autre. Cette technique simplifie l’implémentation de l’enregistrement des
sessions et la conservation en mémoire de calculs précédemment effectués.
Portabilité
Les servlets sont écrits dans le langage de programmation Java et respectent
l’API standard. Par conséquent, des servlets écrits pour I-Planet Enterprise
Server peuvent être exécutés a priori sans modification sur Apache, Internet
Information Server de Microsoft (IIS), WebSphere d’IBM, ou WebStar de StarNine. Par exemple, presque tous les servlets et pages JSP de ce livre ont été
exécutés sur le serveur Web Java de Sun, Apache Tomcat ainsi que sur le JavaServer Web Development Kit (JSWDK), sans aucune modification du code. La
plupart d’entre eux ont été également testés sur WebLogic de BEA et sur
Chapitre 1
Présentation des servlets et des JavaServer Pages
17
WebSphere d’IBM. En fait, les servlets sont supportés soit directement soit par
l’intermédiaire d’un composant logiciel fourni pour tous les principaux serveurs
Web. Ils font désormais partie de la plate-forme Java 2, édition Entreprise (J2EE ;
voir le site http://java.sun.communication/j2ee/), c’est pourquoi le support des
servlets dans le monde industriel se répand de plus en plus.
Sécurité
L’une des principales sources de vulnérabilité des programmes CGI traditionnels
provient du fait qu’ils sont souvent exécutés par des interpréteurs de commandes
généraux. Par conséquent, le programmeur d’un CGI doit être très prudent pour
filtrer certains caractères comme les guillemets inversés et les points-virgules, qui
sont interprétés d’une manière spéciale par l’interpréteur de commandes. Ce
processus reste assez complexe et les sources d’erreurs qui en émanent ne sont
généralement pas abordées dans la plupart des bibliothèques CGI courantes. Une
seconde source d’erreurs provient de ce que certains programmes CGI sont traités
par des langages qui ne vérifient pas automatiquement les limites des tableaux et
des chaînes. Par exemple, en C et en C++, il est parfaitement autorisé d’allouer un
tableau de 100 éléments et d’écrire dans le 999-ième élément, qui peut correspondre à une partie quelconque de la mémoire du programme. Par conséquent, les
programmeurs qui oublient de vérifier explicitement ce type d’accès autorisent
indirectement des attaques volontaires ou involontaires par dépassement de
mémoire. Les servlets ne souffrent d’aucun de ces problèmes. Même si un servlet
exécute un appel sur un système distant pour invoquer un programme sur le
système d’exploitation local, il ne passe par aucun interpréteur de commandes. Et
naturellement, la vérification des limites d’un tableau et les autres techniques de
protection de la mémoire font partie intégrante du langage de programmation Java.
Economique
De nombreux serveurs Web gratuits ou très bon marché sont disponibles, qui sont
parfaitement adaptés pour une utilisation personnelle ou pour des sites Web de
faible importance. Cependant, à l’exception d’Apache, qui est gratuit, la plupart
des serveurs Web de qualité commerciale sont relativement chers. Néanmoins, une
fois que vous possédez un serveur Web, quel qu’en soit le prix, l’ajout des fonctionnalités permettant de supporter les servlets est très économique. Il se peut même
que ce support soit directement intégré dans le serveur Web. Cette solution
18
Partie I
Servlets
contraste avec les options offertes par les CGI, qui nécessitent un investissement
initial non négligeable pour acheter des bibliothèques propriétaires.
JavaServer Pages
La technologie JavaServer Pages (JSP) permet de mélanger du code HTML classique et statique avec du code généré dynamiquement par des servlets. La plupart
des pages Web construites par des CGI sont relativement statiques. Les zones
dynamiques de ces pages sont restreintes à certains emplacements réduits. Par
exemple, la page d’accueil de la plupart des sites d’achat en ligne reste la même
pour tous les visiteurs, à l’exception peut-être d’un message de bienvenue indiquant le nom du visiteur, s’il est connu. Mais la plupart des technologies provenant des CGI, y compris les servlets, doivent créer chaque fois l’intégralité d’une
page grâce à un programme, même si la majeure partie de cette page n’est jamais
modifiée. JSP permet de définir deux zones bien distinctes. Le Listing 1.1 en
montre un bon exemple. L’essentiel de cette page est composé de code HTML
classique, qui est affiché dans le navigateur du visiteur sans aucune modification.
Les parties générées dynamiquement sont désignées par des étiquettes spéciales
ressemblant à des étiquettes HTML. Ces parties sont ensuite intégrées directement dans la page.
Listing 1.1 : Un exemple de page JSP
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>Welcome to Our Store</TITLE></HEAD>
<BODY>
<H1>Welcome to Our Store</H1>
<SMALL>Welcome,
<!-- User name is "New User" for first-time visitors -->
<%= Utils.getUserNameFromCookie(request) %>
To access your account settings, click
<A HREF="Account-Settings.html">here.</A></SMALL>
<P>
Regular HTML for all the rest of the on-line store’s Web page.
</BODY>
</HTML>
Chapitre 1
Présentation des servlets et des JavaServer Pages
19
Avantages des JSP
JSP possède plusieurs
ques-uns :
avantages
par rapport à ses concurrents. En voici quel-
Active Server Pages (ASP)
ASP est une technologie concurrente de Microsoft, par rapport à laquelle JSP
possède deux avantages. Tout d’abord, la partie dynamique est écrite en Java, et
non en VBScript ou en un autre langage spécifique à ASP. Ainsi, JSP est plus
puissant et mieux adapté à des applications complexes nécessitant des composants réutilisables. De plus, JSP est portable vers d’autres systèmes d’exploitation ou d’autres serveurs Web. Vous n’êtes donc pas contraint de vous servir de
Windows NT/2000 et de IIS. Cet argument est également valable pour comparer
JSP et ColdFusion. Avec JSP, vous pouvez utiliser Java, et vous n’êtes pas lié à
un logiciel particulier.
PHP
PHP est un langage à base de scripts, gratuit, inclus dans HTML, dont les sources
sont disponibles, et qui est d’une certaine manière comparable à la fois à JSP et
à ASP. L’avantage de JSP par rapport à PHP est que la partie dynamique est écrite
en Java, que vous connaissez probablement déjà, et qui comporte une API
complète pour l’utilisation des réseaux, des objets distribués, l’accès à des bases
de données, et bien d’autres choses encore, alors que PHP nécessite l’apprentissage d’un langage entièrement nouveau.
Servlets
En principe, tout ce qui peut être réalisé à l’aide de JSP peut aussi l’être avec un
servlet. En fait, les documents JSP sont automatiquement transformés en servlets.
Mais il est plus simple d’écrire et de modifier du code HTML classique plutôt que
de gérer les milliers d’instructions println permettant de générer le code HTML.
De plus, en séparant la présentation et le contenu d’une page, il devient possible
d’affecter différentes personnes à diverses tâches : les experts de conception de
pages Web peuvent construire le code HTML avec leurs outils préférés, et laisser
les programmeurs de servlets insérer le contenu dynamique de la page.
20
Partie I
Servlets
Inclusions au niveau du serveur
Les inclusions au niveau du serveur (SSI, ou Server-Side Includes) sont une technique très répandue pour insérer des éléments externes dans une page Web statique. Une fois encore, JSP est plus intéressant parce qu’il fournit un ensemble
plus riche d’outils pour construire ces éléments externes, et des options plus
nombreuses sur l’insertion de ces éléments dans la réponse HTTP. De plus, SSI
a été conçu uniquement pour des inclusions simples, et non pour celles qui sont
utilisées par des programmes réels faisant intervenir des formulaires, des
connexions à des bases de données, etc.
JavaScript
JavaScript, qu’il ne faut pas confondre avec le langage de programmation Java,
est normalement utilisé pour générer le code HTML dynamique renvoyé au
client, et pour construire des parties de la page Web au fur et à mesure que le
navigateur la charge. Cette capacité est assez utile, mais elle ne permet de gérer
que des situations dans lesquelles les informations dynamiques sont fondées sur
l’environnement du client. Hormis pour les cookies, les données de la requête
HTTP ne sont pas disponibles pour les routines JavaScript au niveau du client.
De plus, comme JavaScript ne dispose d’aucune routine pour la programmation
réseau, le code JavaScript du client ne peut pas accéder aux ressources du
serveur, comme des bases de données, des catalogues, des informations de
prix, etc. JavaScript peut également être utilisé au niveau du serveur, en particulier sur des serveurs Netscape, et en tant que langage de script pour IIS. Java est
bien plus puissant, plus souple, plus fiable et portable.
HTML statique
Naturellement, le code HTML classique ne peut contenir aucune information
dynamique, c’est pourquoi les pages HTML statiques ne peuvent pas être
adaptées en fonction des données saisies par l’utilisateur ou de sources de
données résidant sur le serveur. JSP est tellement simple d’emploi qu’il est
raisonnable de l’ajouter même aux pages HTML qui n’ont pas franchement
besoin de données dynamiques. Auparavant, la difficulté inhérente à l’utilisation
de données dynamiques bannissait celles-ci de la plupart des pages.
Chapitre 1
Présentation des servlets et des JavaServer Pages
21
Installation
Avant de commencer, vous devez charger le logiciel nécessaire et configurer
votre système pour qu’il en tire profit. Voici une présentation des étapes
nécessaires. Cependant, bien que votre code de servlet doive respecter l’API
standard, il n’existe aucun standard pour charger ou configurer des serveurs Web
ou des serveurs d’applications. Par conséquent, et contrairement aux autres
sections de ce livre, les méthodes présentées ici peuvent varier de manière significative d’un serveur à un autre, et les exemples de cette section ne doivent être
considérés que comme des exemples didactiques. Vérifiez la documentation de
votre serveur pour des instructions plus précises.
Obtenir le logiciel de servlets et de JSP
La première étape consiste à charger un logiciel qui implémente les spécifications Java Servlet 2.1 ou 2.2, et JavaServer Pages 1.0 ou 1.1. Si vous exploitez la
dernière version d’un serveur Web ou d’un serveur d’applications, il est probable
qu’il possède déjà tout ce dont vous aurez besoin. Consultez la documentation de
votre serveur, ou la dernière liste de serveurs qui supportent les servlets sur le site
http://java.sun.com/products/servlet/industry.html. Même si vous avez l’intention de développer un serveur de qualité commerciale, il est intéressant dans un
premier temps de disposer d’un système gratuit que vous pourrez installer sur
votre ordinateur personnel pour le développement et les tests. Voici la liste des
logiciels les plus répandus :
m
m
Tomcat d’Apache. Tomcat est l’implémentation de référence officielle des
spécifications JSP 1.1 et servlet 2.2. Il peut être utilisé comme un petit serveur
autonome permettant de tester des servlets et des pages JSP. Il peut également
être intégré dans le serveur Web Apache. Cependant, plusieurs autres serveurs
ont annoncé qu’ils allaient prochainement supporter ces spécifications, c’est
pourquoi nous les étudierons en détail dans ce livre. Tomcat, tout comme
Apache, est gratuit. Néanmoins, et toujours comme Apache (qui est très
rapide, très fiable, mais assez complexe à configurer et à installer), l’installation de Tomcat nécessite une attention plus poussée que pour un moteur de
servlets commercial. Pour plus d’informations, consultez le site http://
jakarta.apache.org/.
JavaServer Web Development Kit (JSWDK). Le JSWDK est l’implémentation de référence officielle des spécifications JSP 1.0 et servlet 2.1. Il est
22
Partie I
Servlets
utilisé comme un petit serveur autonome permettant de tester des servlets et
des pages JSP avant qu’elles soient portées sur un serveur Web complet
supportant ces technologies. Il est gratuit et fiable, mais son installation et sa
configuration sont assez ardues. Pour plus d’informations, consultez le site
http://java.sun.com/products/servlet/download.html.
m
m
m
m
JRun de Allaire. JRun est un moteur de servlets et de JSP qui peut être intégré
dans des serveurs Netscape Enterprise ou FastTrack, dans IIS, Microsoft Personal Web Server, les anciennes versions d’Apache, de WebSite de O’Reilly, ou de
StarNine WebSTAR. Une version limitée supportant jusqu’à cinq connexions
simultanées est disponible gratuitement. La version commerciale ne comporte
pas cette restriction et renferme d’autres caractéristiques intéressantes, comme
une console d’administration à distance. Pour plus d’informations, consultez le
site http://www.allaire.com/products/jrun/.
ServletExec de New Atlanta. ServletExec est un moteur de servlets et de
JSP qui peut être intégré dans la plupart des serveurs Web classiques pour
Solaris, MacOS, HP-UX et Linux. Vous pouvez le charger et l’utiliser gratuitement, mais plusieurs de ses caractéristiques avancées ou de ses outils
d’administration resteront désactivés tant que vous n’achèterez pas de licence.
Pour plus d’informations, consultez le site http://newatlanta.com/.
LiteWebServer (LWS) de Gefion Software. LWS est un petit serveur Web
gratuit dérivé de Tomcat, qui supporte les spécifications JSP 1.1 et servlets 2.2.
Gefion dispose également d’un module logiciel gratuit appelé WAICoolRunner, qui ajoute les spécifications JSP 1.1 et servlets 2.2 aux serveurs
Netscape FastTrack et Enterprise. Pour plus d’informations, consultez le site
http://www.gefionsoftware.com/.
Java Web Server de Sun. Ce serveur a été entièrement écrit en Java et il fait
partie des premiers serveurs à supporter les spécifications JSP 1.0 et servlets 2.1.
Bien qu’il ne soit actuellement plus beaucoup développé par Sun, qui se consacre davantage au serveur Netscape/I-Planet, il constitue toujours une bonne
alternative pour apprendre la technologie des servlets et des JSP. Pour une
version d’évaluation gratuite, consultez le site http://www.sun.com/software/
jwebserver/try/. Pour une version gratuite sans date d’expiration, destinée à
des institutions publiques, consultez le site http://freeware.thesphere.com/.
Chapitre 1
Présentation des servlets et des JavaServer Pages
23
Installer la documentation de l’API servlet et JSP
De même qu’aucun programmeur sérieux ne devrait développer des applications
Java sans accéder à la documentation de l’API du JDK 1.1 ou 1.2, aucun programmeur sérieux ne devrait développer de servlets ou de pages JSP sans accéder à
l’API des classes des bibliothèques javax.servlet. Voici un résumé des sites
fournissant cette API :
m
m
m
http://java.sun.com/products/jsp/download.html. Ce site permet de charger
soit l’API 2.1/1.0 ou l’API 2.2/1.1. Il se peut que vous ayez à charger l’intégralité de l’implémentation de référence avant d’en extraire la documentation.
http://java.sun.com/products/servlet/2.2/javadoc/. Ce site permet de parcourir en ligne l’API 2.2.
http://www.java.sun.com/j2ee/j2sdkee/techdocs/api/. Ce site permet de parcourir l’API complète de la plate-forme Java 2, Enterprise Edition (J2EE), qui
contient les bibliothèques JSP 1.1 et servlets 2.2.
Si Sun ou Apache ajoutent de nouvelles documentations en ligne (c’est-à-dire un
site pour parcourir l’API 2.1/1.0), elles seront listées au Chapitre 1 de l’archive
de sources de ce livre, sur le site http://www.coreservlets.com/.
Installer les classes pour le compilateur Java
Après avoir chargé le logiciel nécessaire, vous devez encore indiquer au compilateur Java (javac) l’emplacement des fichiers de classes JSP et servlet, pour
qu’il puisse compiler vos servlets. Vérifiez la documentation de votre bibliothèque pour plus de détails, mais de manière générale, les fichiers de classes se trouvent dans le dossier lib du dossier d’installation du serveur, les classes de
servlets se trouvant dans servlet.jar et les classes JSP dans jsp.jar, jspengine
.jar ou jasper.jar. Il existe plusieurs manières d’indiquer à javac l’emplacement de ces classes, la plus simple d’entre elles étant de placer les fichiers JAR
dans votre CLASSPATH. Si vous n’avez jamais modifié votre CLASSPATH, il s’agit de
la variable qui spécifie l’emplacement des classes utilisées par le compilateur
pendant la compilation. Si cette variable n’est pas spécifiée, javac cherche dans
le dossier actuel et dans les bibliothèques systèmes standard. Si vous avez défini
vous-même votre CLASSPATH, n’oubliez pas d’y ajouter ".", qui représente le
dossier courant.
24
Partie I
Servlets
Voici un résumé rapide présentant les différentes manières de définir cette variable d’environnement sur diverses plates-formes. Nous supposerons que dir
représente le dossier contenant les classes JSP et servlet.
Unix (C Shell)
setenv CLASSPATH .:dir/servlet.jar:dir/jspengine.jar
Ajoutez :$CLASSPATH à la fin de la ligne setenv si votre CLASSPATH actuel contient
déjà des dossiers et que vous souhaitiez y ajouter d’autres dossiers, sans effacer
les dossiers qui y figurent déjà. Vous remarquerez que sous Unix, les dossiers
sont séparés par des slashs et les différentes entrées par un deux-points. A titre de
comparaison, Windows se sert d’antislashs et de points-virgules. Pour que cette
modification soit permanente, il convient de placer cette instruction dans votre
fichier .cshrc.
Windows
set CLASSPATH=.;dir\servlet.jar;dir\jspengine.jar
Ajoutez ;%CLASSPATH% à la fin de cette ligne si votre CLASSPATH contient déjà des
dossiers que vous souhaitez conserver. Notez que Windows se sert de pointsvirgules et d’antislashs pour séparer les entrées et les dossiers, alors que les
systèmes Unix se servent de deux-points et de slashs. Pour que cette modification
soit permanente sous Windows 95/98, il suffit de placer cette instruction dans
votre fichier autoexec.bat. Sous Windows NT ou 2000, il faut cliquer sur le
bouton Démarrer, sélectionner Paramètres, Panneau de configuration, Système,
Environnement, puis saisir la valeur de cette variable.
Rassembler les classes dans des bibliothèques
Comme vous le verrez au prochain chapitre, vous choisirez probablement de
placer vos servlets dans des bibliothèques, pour éviter les conflits de noms avec
les servlets écrits par d’autres personnes, pour le même serveur Web ou serveur
d’applications. Dans ce cas, il peut être intéressant d’ajouter le dossier principal
de votre bibliothèque dans votre CLASSPATH. Pour plus de détails, voir la section
"Rassembler les servlets dans des bibliothèques", Chapitre 2.
Chapitre 1
Présentation des servlets et des JavaServer Pages
25
Configurer le serveur
Avant de démarrer le serveur, vous pouvez choisir de définir certains paramètres
comme le port sur lequel il écoute, les dossiers dans lesquels il cherche les
fichiers HTML, etc. Ce processus est spécifique à chaque serveur, et les serveurs
Web sérieux devraient toujours fournir une documentation précise sur ce processus d’installation. Cependant, pour les petits serveurs autonomes fournis par Sun
et par Apache comme implémentation de référence des spécifications JSP 1.1/
servlet 2.2 (Tomcat d’Apache), ou 1.0/2.1 (JSWDK de Sun), il existe plusieurs
paramètres importants, mais peu documentés, que nous allons décrire dans les
sections suivantes.
Numéro de port
Tomcat et JSWDK se servent tous les deux par défaut d’un port non standard afin
d’éviter les conflits avec d’autres serveurs Web existants. Si vous commencez par
utiliser l’un de ces deux logiciels pour vos premiers développements et pour les
tester, et que vous ne possédiez aucun autre serveur Web, vous pouvez choisir le
port 80, le port HTTP standard. Avec Tomcat 3.0, vous pouvez apporter cette
modification en éditant le fichier dossier_installation/server.xml et en
remplaçant 8080 par 80 dans la ligne suivante :
<ContextManager port="8080" hostName="" inet="">
Avec le JSWDK 1.0.1, éditez le fichier dossier_installation/webserver.xml et
remplacez 8080 par 80 dans la ligne suivante :
port NMTOKEN "8080"
Java Web Server 2.0 se sert également d’un numéro de port non standard. Pour le
modifier, utilisez l’interface d’administration à distance, disponible sur le site
http://somehostname:9090/, où somehostname peut être remplacé soit par le
nom réel de l’hôte exécutant le serveur, soit par localhost si le serveur est
exécuté sur l’ordinateur local.
Paramètre JAVA_HOME
Si vous vous servez du JDK 1.2 ou 1.3 avec Tomcat ou avec le JSWDK, vous
devez définir la variable d’environnement JAVA_HOME pour qu’elle fasse référence
au dossier d’installation du JDK. Ce paramètre n’est pas nécessaire avec le JDK 1.1.
La méthode la plus simple pour définir cette variable est d’insérer une ligne pour
26
Partie I
Servlets
la définir en haut du script startup (pour Tomcat) ou startserver (pour le
JSWDK). Par exemple, voici le début de la version modifiée des fichiers startup
.bat et startserver.bat que nous utilisons :
rem Marty Hall: added JAVA_HOME setting below
set JAVA_HOME=C:\jdk1.2.2
Paramètres de mémoire DOS
Si vous exécutez Tomcat ou le JSWDK sous Windows 95 ou 98, vous devrez
probablement modifier la quantité de mémoire DOS allouée pour les variables
d’environnement. Pour cela, ouvrez une nouvelle fenêtre DOS, cliquez sur
l’icône MS-DOS dans le coin supérieur gauche de la fenêtre, et sélectionnez
Propriétés. Ensuite, choisissez l’onglet Mémoire, sélectionnez le champ Environnement initial, et saisissez 2816 à la place de Auto. Cette configuration n’a
besoin d’être effectuée qu’une seule fois.
Paramètres CR/LF de Tomcat 3.0
Les premières versions de Tomcat souffraient d’un inconvénient majeur : les
fichiers texte étaient enregistrés au format Unix, dans lequel les fins de lignes
sont désignées par le caractère LF, et non en format Windows, dans lequel une fin
de ligne est représentée par les caractères CR et LF. Par conséquent, les scripts de
démarrage et d’arrêt ne fonctionnaient pas sous Windows. Vous pouvez déterminer facilement si votre version possède ce problème en ouvrant le fichier
install_dir/startup.bat dans un Bloc-notes. Si ce fichier a une apparence
normale, vous possédez une version corrigée. En revanche, si l’intégralité de ce
fichier apparaît sur une seule ligne avec des caractères étranges, quittez le Blocnotes, ouvrez et enregistrez les fichiers suivants sans les modifier, avec Wordpad
(et surtout pas avec le Bloc-notes) :
install_dir/startup.bat
install_dir/tomcat.bat
install_dir/shutdown.bat
install_dir/tomcatEnv.bat
install_dir/webpages/WEB-INF/web.xml
install_dir/examples/WEB-INF/web.xml
Démarrer le serveur
Pour démarrer l’un des "vrais" serveurs Web, consultez sa documentation. Dans
la plupart des cas, vous devrez exécuter une commande appelée httpd, soit à
Chapitre 1
Présentation des servlets et des JavaServer Pages
27
partir de la ligne de commande, soit en demandant au système d’exploitation de
le faire automatiquement lors du premier démarrage de l’ordinateur.
Avec Tomcat 3.0, vous pouvez démarrer le serveur en exécutant un script appelé
startup, situé dans le dossier d’installation. Avec le JSWDK 1.0.1, il suffit
d’exécuter un script similaire appelé startserver.
Compiler et installer vos servlets
Après avoir défini correctement votre CLASSPATH, comme nous venons de le voir
dans cette section, il suffit d’employer la commande "javac ServletName.java"
pour compiler un servlet. Le fichier de classe résultant doit se trouver dans un
emplacement connu du serveur, pour qu’il puisse s’en servir. Comme vous
pouvez vous y attendre, cet emplacement n’est pas le même d’un serveur à un
autre. Voici un petit résumé des dossiers utilisés par les dernières versions de
Tomcat, du JSWDK et du Java Web Server. Dans chacun de ces trois cas, nous
supposerons que install_dir correspond au dossier d’installation du serveur.
Tomcat
m
install_dir/webpages/WEB-INF/classes. Dossier standard des classes de
servlets.
m
install_dir/classes. Dossier de remplacement des classes de servlets.
m
install_dir/lib. Emplacement des fichiers JAR contenant les classes.
Tomcat 3.1
Juste avant l’impression de ce livre, Apache a diffusé une version beta de Tomcat
3.1. S’il existe une version finale de cette version lorsque vous chargez Tomcat,
nous vous conseillons de l’utiliser. Voici la nouvelle organisation des dossiers de
Tomcat 3.1 :
m
install_dir/webapps/ROOT/WEB-INF/classes. Dossier standard des classes de servlets.
m
install_dir/classes. Dossier de remplacement des classes de servlets.
m
install_dir/lib. Emplacement des fichiers JAR contenant les classes.
28
Partie I
Servlets
JSWDK
m
install_dir/webpages/WEB-INF/servlets. Dossier standard des classes de
servlets.
m
install_dir/classes. Dossier de remplacement des classes de servlets.
m
install_dir/lib. Emplacement des fichiers JAR contenant les classes.
Java Web Server 2.0
m
m
m
install_dir/servlets. Ce dossier renferme les classes de servlets qui sont
modifiées régulièrement. Le serveur détecte automatiquement lorsque des
servlets de ce dossier sont modifiés, et il les recharge en cas de besoin. Ce
comportement n’existe pas avec Tomcat ou le JSWDK, avec lesquels il faut
redémarrer le serveur lorsqu’un servlet déjà chargé dans la mémoire du
serveur est modifié. La plupart des serveurs commerciaux possèdent une
option similaire.
install_dir/classes. Emplacement des classes de servlets qui ne sont pas
souvent modifiées.
install_dir/lib. Dossier des fichiers JAR contenant les classes.
Si tout cela peut sembler un peu déconcertant, ne vous inquiétez pas, car au
chapitre suivant nous aborderons ce processus en détail sur plusieurs serveurs
différents, lorsque nous présenterons le code d’un servlet réel.