Java Eclipse Tomcat

Dveloppement web en Java avec Eclipse et
Tomcat
par Serge Tah
Date de publication :
Dernire mise jour :
Ce document est un tutoriel de dveloppement web en Java avec les outils

Eclipse et Tomcat. Il s'appuie sur le document [Introduction la
programmation web en Java]. Des conseils de lecture sont indiqus avant
chaque dveloppement introduisant une notion nouvelle. Aprs ce tutoriel, le
lecteur devrait avoir acquis les points essentiels de la programmation web en
Java.
Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah
I.1 - Objectifs
I.2 - Les outils
I.3 - Le conteneur de servlets Tomcat 5
I.4 - Dploiement d'une application web au sein du serveur Tomcat
I.5 - Installation de plugins Eclipse
I.6 - Lancer-Arrter Tomcat depuis Eclipse
I.7 - Dveloppement d'une application web avec Eclipse/Tomcat
I.7.1 - Cration du contexte de l'application
I.7.2 - Cration d'un document HTML
I.8 - Une page JSP
I.9 - Une servlet
I.9.1 - Configuration de Eclipse
I.9.2 - Ecriture de la servlet
I.9.3 - Dploiement de la servlet dans Tomcat
I.9.4 - Test de la servlet
I.10 - Coopration servlets et pages JSP
I.10.1 - La servlet
I.10.2 - La page JSP
I.10.3 - Dploiement de l'application
I.11 - Une application multi-pages
I.11.1 - Introduction
I.11.2 - Configuration
I.11.3 - Les codes
I.11.4 - Dploiement
I.11.5 - Tests
I.12 - Gestion d'une session
I.12.3 - Les codes
I.12.4 - Dploiement
I.12.5 - Tests
I.13 - Scripts ct navigateur
I.13.1 - Le nouveau formulaire
I.13.2 - Configuration et dploiement
I.13.3 - Tests
I.14 - Utiliser des bibliothques de balises
I.15 - Crer une page d'accueil
I.16 - Dveloppement MVC
I.16.2 - Une dmarche de dveloppement MVC en Java!
I.16.3 - Pour approfondir le dveloppement web MVC
I.16.4 - Tlchargements
-2Les sources prsents sur cette pages sont libres de droits, et vous pouvez les utiliser votre convenance. Par contre la page
de prsentation de ces sources constitue une oeuvre intellectuelle protge par les droits d'auteurs. Copyright 2005Serge
Tah . Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents,
images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000
E de domages et intrets.
I.1 - Objectifs
On se propose ici de dcouvrir la programmation web en Java par une srie de tests pratiques sur
ordinateur. Si les copies d'cran ci-dessous ont t faites sous windows, les tests eux, pourraient tre
faits indiffremment sous Windows ou Linux. A la fin de cette srie de manipulations qui devrait durer
2 3 TD, le lecteur devrait avoir acquis les concepts de base de la programmation web en java.
Afin d'avoir la comprhension de ce qui est fait, l'usage du polycopi "Introduction la programmation
web en Java" est ncessaire. Des conseils de lecture sont donns avant la plupart des tests
raliser.
I.2 - Les outils

Nous utiliserons pour ces tests les outils suivants :
le serveur web TOMCAT (http://jakarta.apache.org/tomcat/),

l'outil de dveloppement java ECLIPSE (http://www.eclipse.org/) avec les plugins suivants :
XmlBuddy pour grer les documents XML (http://xmlbuddy.com/)
Tomcat de Sysdeo (http://www.sysdeo.com/eclipse/tomcatPlugin.html) pour grer Tomcat

partir d'Eclipse
un navigateur (IE, NETSCAPE, MOZILLA, OPERA, ...) :
Ce sont des outils gratuits. De nombreux outils libres peuvent tre utiliss dans le dveloppement
Web :
I.3 - Le conteneur de servlets Tomcat 5

Pour excuter des servlets, il nous faut un conteneur de servlets. Nous prsentons ici l'un d'eux,
Tomcat 5 disponible l'url http://jakarta.apache.org/tomcat/. Nous indiquons la dmarche (aot 2004)
pour l'installer pour le lecteur intress par l'installer sur son poste personnel.
Pour tlcharger le produit, on suivra le lien [Binaries] ci-dessus. On arrive alors une page
rassemblant tous les binaires des diffrents sous-projets du projet Jakarta de l'Apache Software
Foundation. Nous choisissons celui de Tomcat 5 :
On pourra prendre le .zip ou le .exe destin la plate-forme windows. Le .exe est conseill car il vient
avec un assistant d'installation. Tomcat est une application Java et a donc besoin d'une machine
virtuelle java (JVM) sur la plate-forme d'installation. Comme beaucoup d'applications Java, Tomcat
utilise la variable d'environnement JAVA_HOME si elle est prsente. Celle-ci doit dsigner le dossier
d'installation d'un JDK (Java Development Kit) ou d'un JRE (Java Runtime Environment). Sur une
machine Windows XP une variable d'environnement peut tre cre de la faon suivante :
Menu Dmarrer -> Panneau de configuration -> Systme -> Onglet [Avanc] -> Bouton [Variables d'environnement] ->
Ici JAVA_HOME dsigne un JDK de Sun dont l'arborescence est la suivante :
Tout JDK rcent de Sun fera l'affaire. La variable d'environnement peut ncessiter un redmarrage du
systme pour tre prise en compte. Une fois la variable d'environnement JAVA_HOME dfinie,
l'installation de Tomcat peut tre faite. Au cours de celle-ci, l'installateur va demander le dossier
contenant la JVM. Il prsente dans une liste droulante les dossiers susceptibles de contenir une
JVM. Ces informations sont obtenues soit par la variable JAVA_HOME soit par des cls de registres.
La JVM et correspondant la variable JAVA_HOME devrait tre dans la liste des JVM prsentes. Ce
sera la seule s'il n'y a pas d'autres JVM sur la machine. On slectionnera la JVM de son choix. La
gestion de Tomcat via le web ncessite de s'authentifier via une page de login/mot de passe. Deux
utilisateurs spciaux sont appels admin et manager. Au cours de l'installation de Tomcat, il nous est
demand de fixer le mot de passe de l'utilisateur admin. Dans La suite, nous supposerons que ce mot
de passe est admin. L'installation de Tocat se fait dans un dossier choisi par l'utilisateur, que nous
appellerons dsormais <tomcat>. L'arborescence de ce dossier pour la version Tomcat 5.0.27
ci-dessus est la suivante :
L'installation de Tomcat 5.0.27 a amen un certain nombre de raccourcis dans le menu [Dmarrer].
Nous utilison le lien [Monitor] ci-dessous pour lancer l'outil d'arrt/dmarrage de Tomcat :
Une icne est insre dans la barre des tches en bas droite de l'cran :
Le moniteur de Tomcat est activ par un double-clic sur cette icne :
Les boutons [Start - Stop - Pause] - Restart nous permettent de lancer - arrter - relancer le serveur.
Nous lanons le serveur par [Start] puis avec un navigateur nous demandons l'url
http://localhost:8080. Nous devons obtenir une page analogue la suivante :
On pourra suivre les liens ci-dessous pour vrifier la correcte installation de Tomcat :!
Tous les liens de la page [http://localhost:8080] prsentent un intrt et le lecteur est invit les
explorer. Nous aurons l'occasion de revenir sur les liens permettant de grer les applications web
dployes au sein du serveur :I
I.4 - Dploiement d'une application web au sein du serveur Tomcat

Une application web doit suivre certaines rgles pour tre dploye au sein d'un conteneur de
servlets. Soit <webapp> le dossier d'une application web. Une application web est compose de :
L'application web est configure par un fichier XML : <webapp>\WEB-INF\web.xml.

Construisons l'application web dont l'arborescence est la suivante :
Les dossiers [classes] et [lib] sont ici vides. L'application n'ayant pas de classes, le fichier
WEB-INF\web.xml est inutile et n'est donc pas prsent. Le dossier [vues] contient un fichier html
statique :
dont le contenu est le suivant :@

<html>
<head>
<title>Application exemple</title>
</head>
<body>
Application exemple active ....
</body>
</html>
Si on charge ce fichier dans un navigateur, on obtient la page suivante :

- 10 Les sources prsents sur cette pages sont libres de droits, et vous pouvez les utiliser votre convenance. Par contre la page
L'URL affiche par le navigateur montre que la page n'a pas t dlivre par un serveur web mais
directement charge par le navigateur. Nous voulons maintenant qu'elle soit disponible via le serveur
web Tomcat.
Revenons sur l'arborescence du rpertoire <tomcat> :
La configuration des applications web dployes au sein du serveur Tomcat se fait l'aide de fichiers
XML placs dans le dossier <tomcat>\conf\Catalina\localhost :
Ces fichiers XML peuvent tre crs la main car leur structure est simple. Plutt que d'adopter cette
dmarche, nous allons utiliser les outils web que nous offre Tomcat. Sur sa page d'entre
http://localhost:8080, le serveur nous offre des liens pour l'administrer :
Le lien [Tomcat Administration] nous offre la possibilit de configurer les ressources mises par Tomcat
la disposition des applications web dploye en son sein. Un exemple classique est un pool de
connexions une base de donnes. Suivons le lien. Nous obtenons une page d'identification :
Ici, il faut redonner les informations que nous avons donnes au cours de l'installation de Tomcat.
Dans notre cas, nous donnons le couple admin/admin. Le bouton [Login] nous amne la page
suivante :
Cette page permet l'administrateur de Tomcat de dfinir
des sources de donnes (Data Sources),

les informations ncessaires l'envoi de courrier (Mail Sessions),
des donnes d'environnement accessibles toutes les applications (Environment Entries),
de grer les utilisateurs/administrateurs de Tomcat (Users),
de grer des groupes d'utilisateurs (Groups),
de dfinir des rles (= ce que peut faire ou non un utilisateur),
de dfinir les caractristiques des applications web dployes par le serveur (Service Catalina)
Suivons le lien [Roles] ci-dessus :
Un rle permet de dfinir ce que peut faire ou ne pas faire un utilisateur ou un groupe d'utilisateurs.
On associe un rle certains droits. Chaque utilisateur est associ un ou plusieurs rles et dispose
des droits de ceux-ci. Le rle [manager] ci-dessous donne le droit de grer les applications web
dployes dans Tomcat (dploiement, dmarrage, arrt, dchargement). Nous allons crer un
utilisateur [manager] qu'on associera au rle [manager] afin de lui permettre de grer les applications
de Tomcat. Pour cela, nous suivons le lien [Users] de la page d'administration :
Nous voyons qu'un certain nombre d'utilisateurs existent dj. Nous utilisons l'option [Create New
User] pour crer un nouvel utilisateur :
Nous donnons l'utilisateur manager le mot de passe manager et nous lui attribuons le rle manager.
Nous utilisons le bouton [Save] pour valider cet ajout. Ce nouvel utlisateur va tre ajout dans le
fichier <tomcat>\conf\tomcat-users.xml :
dont le contenu est le suivant :@

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="manager"/>
<role rolename="admin"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
<user username="manager" password="manager" fullName="" roles="manager"/>
<user username="admin" password="admin" roles="admin,manager"/>
</tomcat-users>
Une autre faon d'ajouter des utilisateurs est donc de modifier directement ce fichier. C'est notamment
ainsi qu'il faut procder si d'aventure on a oubli le mot de passe de l'administrateur admin.
Revenons maintenant la page d'entre [http://localhost:8080] et suivons le lien [Tomcat Manager] :
Nous obtenons alors une page d'authentification. Nous nous identifions comme manager/manager,
c.a.d. l'utilisateur de rle [manager] que nous venons de crer. En effet, seul un utilisateur ayant ce
rle peut utiliser ce lien :
Nous obtenons une page listant les applications actuellement dployes dans Tomcat :
Nous pouvons ajouter une nouvelle application grce des liens trouvs en bas de la page :
Ici, nous voulons dployer au sein de Tomcat, l'application exemple que nous avons construite
prcdemment. Nous le faisons de la faon suivante :
Pour obtenir le fichier [D:\data\serge\devel\web\servlets\exemple\vues\exemple.html], nous

demanderons Tomcat l'URL [http://localhost:8080/exemple/vues/exemple.html]. Le contexte sert
donc donner un nom la racine de l'arborescence de l'application web dploye. Nous utilisons le
bouton [Deploy] pour effectuer le dploiement de l'application. Si tout se passe bien, nous obtenons la
page rponse suivante :
et la nouvelle application apparat dans la liste des applications dployes :
Commentons la ligne du contexte /exemple ci-dessus :
Le dploiement a eu pour effet d'ajouter un nouveau descripteur XML dans le dossier

<tomcat>\conf\Catalina\localhost :
Le fichier exemple.xml dcrit l'application web ajoute :

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="D:/data/serge/devel/web/servlets/exemple" path="/exemple">
</Context>
On retrouve tout simplement ce que nous avons saisi dans la page web de dploiement. Une autre
faon de procder est donc la suivante :
1
2
3
crire la main le descripteur XML de l'application dployer

mettre ce descripteur dans le dossier <tomcat>\conf\Catalina\localhost
arrter et relancer Tomcat
Maintenant que notre application /exemple est dploye, nous pouvons faire quelques tests. Tout
d'abord, nous demandons l'url racine du contexte http://localhost:8080/exemple/ :
Nous obtenons une liste du contenu du dossier associ au contexte /exemple. Cependant le dossier
WEB-INF d'une application web n'est lui jamais prsent. Nous pouvons demander la page
exemple.html via l'url http://localhost:8080/exemple/vues/exemple.html :
I.5 - Installation de plugins Eclipse

Nous allons avoir besoin dans la suite de plugins pour l'IDE Eclipse, notamment le plugin qui va
permettre de grer Tomcat depuis Eclipse. Nous prsentons ici une mthode possible d'installation
d'un plugin Eclipse. Nous tlchargeons le plugin Tomcat de Sysdeo :
Nous obtenons un zip dont la structure (partielle) est la suivante :
Le contenu du fichier zip est install dans [<eclipse>\plugins] o <eclipse> est le dossier d'installation
d'Eclipse :
Ceci fait, nous pouvons lancer Eclipse qui va alors intgrer la prsence d'un nouveau plugin. Avant de
pouvoir utiliser le plugin Tomcat il nous faut le configurer. Cela se fait par l'option de menu
[Window/Preferences] :
On dfinit :
1
2
3
4
la version de Tomcat installe sur le poste

le dossier o il a t install
le mode de dclaration des contextes des applications web
le rpertoire des contextes
Les plugins utiles installer pour le dveloppement web en Java sont les suivants :
XmlBuddy pour la gestion des documents Xml (http://xmlbuddy.com/)

Lomboz pour la gestion des documents JSP (http://www.objectlearn.com/)
I.6 - Lancer-Arrter Tomcat depuis Eclipse

Pour grer Tomcat depuis Eclipse, nous disposons de trois boutons dans la barre d'outils :
De gauche droite : Lancer Tomcat - Arrter Tomcat - Relancer Tomcat (Arrt+Redmarrage)

On dispose galement d'un menu :
Lanons Tomcat. Le serveur est lanc et crit des logs dans la fentre [Console] :
La comprhension de ces logs demande une certaine habitude. Nous ne nous apesantirons pas
dessus pour le moment. Il est cependant important de regarder que ces logs ne signalent pas
d'erreurs de chargement de contextes. En effet, lorsqu'il est lanc, Tomcat va chercher charger le
contexte des applications dont il trouve les dfinitions soit dans le fichier [<tomcat>\conf\server.xml]
soit dans le dossier [<tomcat>\conf\Catalina\localhost]. Charger le contexte d'une application implique
d'exploiter le fichier [web.xml] de l'application et de charger une ou plusieurs classes initialisant
celle-ci. Plusieurs types d'erreurs peuvent alors se produire :
le fichier [web.xml] est syntaxiquement incorrect. C'est l'erreur la plus frquente. Il est conseill
d'utiliser un outil capable de vrifier la validit d'un document XML lors de sa construction. Ce
sera le rle du plugin XmlBuddy que nous avons adjoint Eclipse.
certaines classes charger n'ont pas t trouves. Elles sont cherches dans
[WEB-INF/classes] et [WEB-INF/lib]. Il faut en gnral vrifier la prsence des classes

ncessaires et l'orthographe de celles dclares dans le fichier [web.xml].
Pour vrifier la prsence de Tomcat, prenez un navigateur et demandez l'url [http://localhost:8080] :
I.7 - Dveloppement d'une application web avec Eclipse/Tomcat

I.7.1 - Cration du contexte de l'application
Nous sommes maintenant prts dvelopper une premire application web avec Eclipse/Tomcat.
Nous reprenons une dmarche analogue celle utilise pour crer une application web sans Eclipse.
Eclipse lanc, nous crons un nouveau projet :
que nous dfinissons comme un projet Tomcat :
La premire page de l'assistant de cration nous prcisons le nom du projet [1] et son emplacement
[2] :p
La seconde page de l'assistant nous demande de dfinir le contexte [3] de l'application :
Une fois l'assistant valid, Eclipse cre le projet Tomcat avec l'arborescence suivante :
WEB-INF/src : contiendra le code Java des classes de l'application
WEB-INF/classes (non reprsent) : contiendra les .class des classes compiles ainsi qu'une
copie de tous les fichiers autres que .java placs dans WEB-INF/src. Une application web utilise
frquemment des fichiers dits "ressource" qui doivent tre dans la mme arborescence que les
classes, c.a.d. dans WEB-INF/classes. On les place alors dans le dossier WEB-INF/src sachant
qu'Eclipse les recopiera automatiquement dans WEB-INF/classes.

WEB-INF/lib : contiendra les archives .jar dont a besoin l'application web. work : contiendra le
code .java des servlets gnres partir des pages JSP de l'application.
Aprs la cration du projet Tomcat, nous pouvons constater qu'une nouvelle application est apparue
dans le dossier dans [<tomcat>\conf\Catalina\localhost] :
Son contenu est le suivant :

<Context path="/personne" reloadable="true" docBase="D:\data\serge\travail\2004-2005\webjava\personne"
workDir="D:\data\serge\travail\2004-2005\webjava\personne\work" />
Si nous lanons Tomcat et examinons ses logs dans la fentre [Console] d'Eclipse, nous constatons
que la nouvelle application a t prise en compte :
Nous pouvons le vrifier. Demandons le contexte /personne via l'url http://localhost:8080/personne :
Le plugin [Tomcat] nous permet de supprimer un contexte au sein du serveur Tomcat. Pour cela, dans
Eclipse cliquez droit sur le projet et prenez l'option [Projet Tomcat/Suppression du contexte] :
Nous pouvons constater que le fichier [<tomcat>\conf\Catalina\localhost\personne.xml] a disparu :
Pour recrer le contexte, on prendra l'option [Projet Tomcat/Mise jour du contexte]. Le fichier
[personne.xml] rapparat alors dans le dossier [<tomcat>\conf\Catalina\localhost] et les logs de
Tomcat indiquent que le chargement du nouveau contexte a eu lieu :
I.7.2 - Cration d'un document HTML

Nous crons maintenant un document HTML statique [formulaire.html] dans le dossier [personne] :
Pour le crer, cliquez droit sur le projet [personne] puis prenez l'option [New/File] et appelez
[formulaire.html] le nouveau fichier. Ce document HTML affichera un formulaire demandant le nom et
l'ge d'une personne. Son contenu sera le suivant :
<html>
<head>
<title>Personne - formulaire</title>
</head>
<body>
<center>
<h2>Personne - formulaire</h2>
<hr>
<form action="" method="post">
<table>
<tr>
<td>Nom</td>
<td><input name="txtNom" value="" type="text" size="20"></td>
</tr>
<tr>
<td>Age</td>
<td><input name="txtAge" value="" type="text" size="3"></td>
</tr>
</table>
<table>
<tr>
<td><input type="submit" value="Envoyer"></td>
<td><input type="reset" value="Retablir"></td>
<td><input type="button" value="Effacer"></td>
</tr>
</table>
</form>
</center>
</body>
</html>
Sauvegardez ce document dans le dossier <personne>. Lancez Tomcat. Nous allons tout d'abord
vrifier que le contexte [/personne] existe bien au sein de Tomcat. Avec un navigateur demandez
l'URL http://localhost:8080/personne :
On obtient une page qui liste le contenu du dossier physique associ au contexte [/personne]. On y
voit [formulaire.html] accessible via un lien. Le premier test faire lors du dploiement d'une
application web est de vrifier, comme nous l'avons fait ici, que le contexte de l'application est
accessible. S'il ne l'est pas, il est inutile d'aller plus loin. Que faire si cette tape choue ? Prenons le
cas suivant o nous faisons une faute d'orthographe sur le nom du contexte :
Lorsqu'un contexte est inaccessible, on vrifiera les points suivants :
l'orthographe du contexte
les logs de Tomcat dans Eclipse. Ils peuvent signaler une erreur lors du chargement du contexte
de notre application. Ci-dessous, on voit les logs lis au traitement du fichier [personne.xml] :
le contenu du fichier [web.xml] qui dfinit l'application web.
Une fois la page du contexte /personne obtenu, nous pouvons suivre le lien [formulaire.html] :
I.8 - Une page JSP

Nous dupliquons notre document formulaire.html dans un fichier formulaire.jsp dans le mme dossier
puis nous transformons le texte de [formulaire.jsp] la faon suivante :

<%
String nom=request.getParameter("txtNom");
if(nom==null) nom="inconnu";
String age=request.getParameter("txtAge");
if(age==null) age="xxx";
%>
<html>
<head>
</head>
<body>
<center>
<hr>
<table>
<tr>
<td>Nom</td>
<td><input name="txtNom" value="<%= nom %>" type="text" size="20"></td>
</tr>
<tr>
<td>Age</td>
<td><input name="txtAge" value="<%= age %>" type="text" size="3"></td>
</tr>
</table>
<table>
<tr>
<td><input type="reset" value="Rtablir"></td>
</tr>
</table>
</form>
</center>
</body>
</html>
Le document initialement statique est maintenant devenu dynamique par introduction de code Java.
Pour ce type de document, nous procderons toujours comme suit :
nous mettons du code Java ds le dbut du document pour rcuprer les paramtres
ncessaires au document pour s'afficher. Ceux-ci seront le plus souvent dans l'objet request. Cet
objet reprsente la requte du client. Celle-ci peut passer au travers de plusieurs servlets et
pages JSP qui ont pu l'enrichir. Ici, elle nous arrivera directeement du navigateur
le code HTML se trouve la suite. Il se contentera le plus souvent d'afficher des variables
calcules auparavant dans le code Java au moyen de balises <%= variable %>. On notera ici
que le signe = est coll au signe %. C'est une cause frquente d'erreurs.
Que fait le document dynamique prcdent ?
il rcupre dans la requte, deux paramtres appels [txtNom] et [txtAge]. S'il ne les trouve pas,
il leur donne des valeurs par dfaut.
il affiche la valeur de ces deux paramtres dans le code HTML qui suit
Faisons
un
premier
test.
Avec
http://localhost:8080/personne/formulaire.jsp :
un
navigateur,
demandons
l'URL
Le document formulaire.jsp a t appel sans passage de paramtres. Les valeurs par dfaut ont
donc
t
affiches.
Maintenant
demandons
l'URL
http://localhost:8080/personne/formulaire.jsp?txtNom=martin&txtAge=14 :
Cette fois-ci, nous avons pass au document formulaire.jsp, les paramtres txtNom et txtAge qu'il
attend. Il les a donc affichs. On sait qu'il y a deux mthodes pour passer des paramtres un
document web : GET et POST. Dans les deux cas, les paramtres passs se retrouvent dans l'objet
prdfini request. Ici, ils ont t passs par la mthode GET.h
I.9 - Une servlet

I.9.1 - Configuration de Eclipse
Nous nous proposons ici de crer une servlet faisant la mme chose que la page JSP prcdente.
Une servlet est une classe Java. Nous l'appellerons ServletFormulaire. Une servlet drive de la classe
javax.servlet.http.Servlet. Les classes javax.servlet.* ne sont pas partie du Java standard et ne sont
donc pas trouves par dfaut dans un projet Java sous Eclipse. Il nous faut configurer le projet afin
que son [ClassPath] inclue les dossiers contenant les bibliothques .jar des classes ncessaires au
dveloppement web. Sous Eclipse, cliquons droit sur le nom du projet [personne] et accdons ses
proprits ou bien prenons le menu [Project/Properties] puis l'option [Java Build Path] de ces
proprits. Cette option fixe les dossiers et bibliothques explorer pour trouver toutes les classes
ncessaires l'application.
Nous constatons que dans le [Java Build Path] de l'application se trouvent des archives situes dans
l'arborescence de Tomcat. Celles-ci contiennent les classes du paquetage [javax.servlet] dont nous
avons besoin. C'est parce que nous cr un projet [Java/Tomcat] que ces archives ont t
automatiquement ajoutes au [Java Build Path] de l'application.h
I.9.2 - Ecriture de la servlet

Nous sommes maintenant prts pour crire la classe servletFormulaire. Sous Eclipse, cliquons droit
sur le dossier [WEB-INF/src] et prenons l'option de cration d'une classe :
puis dfinissons les caractristiques de la classe crer :
Vous adapterez le nom du paquetage en remplaant [st] par votre nom. Aprs validation de l'assistant,
le projet est modifi de la faon suivante :
La classe [ServletFormulaire] a t cre avec un squelette de code :

package istia.st.servlets.personne;
import javax.servlet.http.HttpServlet;
public class ServletFormulaire extends HttpServlet {
}
Nous compltons ce code avec le contenu suivant :

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletFormulaire extends HttpServlet {
// paramtres d'instance
private String defaultNom = null;
private String defaultAge = null;
//init
public void init() {
// on rcupre les paramtres d'initialisation de la servlet
ServletConfig config = getServletConfig();
defaultNom = config.getInitParameter("defaultNom");
if(defaultNom==null) defaultNom="NNNNNNNNNNNNNNN";
defaultAge = config.getInitParameter("defaultAge");
if(defaultAge==null) defaultAge="AAA";
}
//GET
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException,
ServletException {
// on rcupre les paramtres du formulaire
String nom = request.getParameter("txtNom");
if (nom == null) {
nom = defaultNom;
}
String age = request.getParameter("txtAge");
if (age == null) {
age = defaultAge;
}
// on affiche le formulaire
response.setContentType("text/html");
PrintWriter out=response.getWriter();
out.println(
"<html>"+
"<head>"+
"<title>Personne - formulaire</title>"+
"</head>"+
"<body>"+
"<center>"+
"<h2>Personne - formulaire</h2>"+
"<hr>"+
"<form action='' method='post'>"+
"<table>"+
"<tr>"+
"<td>Nom</td>"+
"<td><input name='txtNom' value='"+nom+"' type='text' size='20'></td>"+
"</tr>"+
"<tr>"+
"<td>Age</td>"+
"<td><input name='txtAge' value='"+ age +"' type='text' size='3'></td>"+
"</tr>"+
"</table>"+
"<table>"+
"<tr>"+
"<td><input type='submit' value='Envoyer'></td>"+
"<td><input type='reset' value='Rtablir'></td>"+
"<td><input type='button' value='Effacer'></td>"+
"</tr>"+
"</table>"+
"</form>"+
"</center>"+
"</body>"+
"</html>"
);
}
/**
* @param request la requte HTTP du client
* @param response la rponse HTTP qu'on va construire
*/
public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException,
ServletException {
// on passe la main au GET
doGet(request, response);
}
}
A la simple lecture de la servlet, on peut constater tout de suite qu'elle est beaucoup plus complexe
que la page JSP correspondante. C'est une gnralit : une servlet n'est pas adapte pour gnrer du
code HTML. Ce sont les pages JSP qui sont faites pour cela. Nous aurons l'occasion d'y revenir.
Explicitons quelques points importants de la servlet ci-dessus :
lorsqu'une servlet est appele pour la 1re fois, sa mthode init est appele. C'est le seul cas o
elle est appele.
si la servlet a t appele par la mthode HTTP GET, la mthode doGet est appele pour traiter
la requte du client.
si la servlet a t appele par la mthode HTTP POST, la mthode doPost est appele pour
traiter la requte du client.
La mthode init sert ici rcuprer des valeurs appeles defaultNom et defaultAge. Pour l'instant, on
ne sait pas o elle les rcupre. Ce sont des valeurs de configuration de la servlet qui ne changent
pas au fil des cycles requte-rponse. La mthode init excute au chargement initial de la servlet est
donc le bon endroit pour les rcuprer.
La mthode doPost renvoie la mthode doGet. Cela signifie que le client pourra envoyer
indiffremment ses paramtres par un POST ou un GET.
La mthode doGet :
reoit deux paramtres request et response. request est un objet reprsentant la totalit de la
requte du client. Elle est de type HttpServletRequest qui est une interface. response est de type
HttpServletResponse qui est galement une interface. L'objet response sert envoyer une
rponse au client.
request.getparameter("param") sert rcuprer dans la requte du client la valeur du paramtre

de nom param.
response.getWriter() sert obtenir un flux d'criture vers le client
response.setContentType(String) sert fixer la valeur de l'entte HTTP Content-type. On

rappelle que cet entte indique au client la nature du document qu'il va recevoir. Le type
text/html indique un document HTML.
La compilation de cette servlet va produire un fichier .class dans le dossier [WEB-INF/classes] :
Le lecteur est invit consulter l'aide Java sur les servlets. On pourra pour cela s'aider de Tomcat.
Sur la page d'entre de Tomcat 5, on a un lien [Documentation] :
Ce lien mne une page que le lecteur est invit explorer. Le lien sur la documentation des servlets
est le suivant :?
I.9.3 - Dploiement de la servlet dans Tomcat

Une fois la servlet prcdente correctement compile par Eclipse, il faut la faire prendre en compte
par le serveur Tomcat. Pour cela, il nous faut crire le fichier de configuration [web.xml] de
l'application. Ce fichier est placer dans le dossier WEB-INF de l'application :
Pour le construire, nous allons utiliser un assistant. Nous cliquons droit sur le dossier [WEB-INF] et
prenons l'option [New/Other] pour arriver la premire page d'un assistant :
Nous prenons l'option [XML/XML Document] puis les options suivantes :
La plupart des options prises ci-dessus sont les options proposes par dfaut. Le fichier [web.xml]
gnr par l'assistant est le suivant :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app SYSTEM "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
</web-app>
Le fichier reprend ce qui a t positionn dans l'assistant. Aussi la plupart du temps, peut-on se
contenter de crer un fichier [web.xml] par copier/coller. L'icne associe au fichier [web.xml] indique
que son contenu est pris en charge par le plugin [XmlBuddy] :
Le contenu d'un fichier XML est le plus souvent contrl par un document appel une DTD (Document
Type Definition) qui dfinit les balises que peut contenir le document ainsi que la hirarchie de
celles-ci
l'intrieur
du
document.
Ici
la
DTD
utilise
se
trouve
l'url
[http://java.sun.com/dtd/web-app_2_3.dtd] comme l'indique l'entte [DOCTYPE] du fichier [web.xml]
prcdent. Afin que XMlBuddy ait accs cette DTD, le poste doit avoir accs au rseau. Dans les
salles de l'ISTIA, les postes n'ont un accs HTTP au rseau Internet que via une machine proxy de
nom [eproxy.istia.uang] et le port [3128]. Il faut s'assurer que le proxy d'Eclipse est correctement
positionn. Pour cela, on utilise l'option [Window/Preferences/Install-Update] :
Ceci fait, XmlBuddy va pouvoir signaler les erreurs dans [web.xml]. C'est une aide indispensable car il
est facile de faire des erreurs telles que celle d'oublier de fermer une balise. Le fichier web.xml de
notre application personne sera le suivant :
<!DOCTYPE web-app SYSTEM "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<servlet>
<servlet-name>formulairepersonne</servlet-name>
<servlet-class>istia.st.servlets.personne.ServletFormulaire</servlet-class>
<init-param>
<param-name>defaultNom</param-name>
<param-value>inconnu</param-value>
</init-param>
<init-param>
<param-name>defaultAge</param-name>
<param-value>XXX</param-value>
</init-param>
</servlet>
<servlet-mapping>
<url-pattern>/formulaire</url-pattern>
</servlet-mapping>
</web-app>
Les points principaux de ce fichier de configuration sont les suivants :
ce qui prcde la balise <web-app> est reprendre intgralement dans tout fichier de
configuration
la configuration se fait entre les balises <web-app> et </web-app>
la configuration d'une servlet se fait entre les balises <servlet> et </servlet>. Une application
peut comporter plusieurs servlets et donc autant de sections de configuration
<servlet>...</servlet>.
la balise <servlet-name> fixe un nom la servlet - peut tre quelconque
la balise <servlet-class> donne le nom complet de la classe correspondant la servlet. Vous

donnerez le nom exact de votre classe qui sera sans doute diffrent de celui dclar ci-dessus.
Tomcat ira chercher cette classe dans le dossier [WEBINF/ classes] de l'application :
la balise <init-param> sert passer des paramtres de configuration la servlet. Ceux-ci sont
gnralement lus dans la mthode init de la servlet car les paramtres de configuration de
celle-ci doivent tre connus ds son premier chargement.
la balise <param-name> fixe le nom du paramtre et <param-value> sa valeur.
la balise <servlet-mapping> sert associer une servlet (servlet-name) un modle d'URL
(url-pattern). Ici le modle est simple. Il dit qu' chaque fois qu'une URL aura la forme
/formulaire, il faudra utiliser la servlet formulairepersonne, c.a.d. la classe
[istia.st.servlets.ServletFormulaire].
I.9.4 - Test de la servlet

Nous en savons assez pour faire un test. Lanons le serveur Tomcat si besoin est. S'il tait dj
lanc, les modifications faites au fichier [web.xml] ont du l'amener recharger le contexte de
l'application. Ce point est affich dans les logs :
4 nov. 2004 10:57:14 org.apache.catalina.core.StandardContext reload

Le rechargement de ce contexte a dmarr
4 nov. 2004 10:59:56 org.apache.catalina.startup.HostConfig restartContext
INFO: restartContext(/personne)!
Demandons l'URL [http://localhost:8080/personne/formulaire] avec un navigateur. Nous demandons

ici la ressource [/formulaire] du contexte [/personne]. Le fichier [web.xml] de ce contexte indique que la
ressource [/formulaire] est assure par la servlet de nom [/formulairePersonne]. Dans le mme fichier,
il est indiqu que cette servlet est la classe [istia.st.servlets.ServletFormulaire]. C'est donc cette
classe que Tomcat va confier le traitement de la requte client. Si la classe n'tait pas dj charge,
elle le sera. Elle restera alors en mmoire pour les futures requtes.P
L'url [http://localhost:8080/personne/formulaire] donne le rsultat suivant :
Nous obtenons les valeurs par dfaut du nom et de l'ge. Demandons maintenant l'URL
[http://localhost:8080/personne/formulaire?txtNom=tintin&txtAge=30] :
Nous obtenons bien les paramtres passs dans la requte.
I.10 - Coopration servlets et pages JSP

I.10.1 - La servlet
Nous avons vu que la servlet tait mal adapte pour gnrer du code HTML alors que la page JSP
elle, tait bien adapte. Par la suite, nous construirons nos applications de la faon suivante :
les pages renvoyes en rponses aux demandes des clients seront gnres uniquement par
des documents JSP. Ceux-ci seront paramtrs, ce qui leur donnera leur aspect dynamique.
la logique de traitement des requtes du client et le calcul des paramtres ncessaires

l'affichage des rponses sera assur par une ou plusieurs servlets.
Pour exemple, reprenons l'exemple de la servlet prcdente [ServletFormulaire] et enlevons-lui toute

la gnration du code HTML de la rponse. Appelons cette nouvelle servlet ServletFormulaire2. Elle
sera construite dans le mme projet [personne] que prcdemment ainsi que toutes les servlets
venir. Son code est le suivant :
public class ServletFormulaire2 extends HttpServlet {
private String defaultNom = null;
private String defaultAge = null;
//init
defaultNom = config.getInitParameter("defaultNom");
if(defaultNom==null) defaultNom="NNNNNNNNNNNNNNN";
defaultAge = config.getInitParameter("defaultAge");
if(defaultAge==null) defaultAge="AAA";
}
//GET
ServletException {
// on rcupre les paramtres du formulaire
String nom = request.getParameter("txtNom");
if (nom == null) {
nom = defaultNom;
}
String age = request.getParameter("txtAge");
if (age == null) {
age = defaultAge;
}
request.setAttribute("nom",nom);
request.setAttribute("age",age);
getServletContext().getRequestDispatcher("/formulaire2.jsp").forward(request,response);
} //GET
//POST
ServletException {

}
}
Seule la partie gnration de la rponse a chang :

getServletContext().getRequestDispatcher("/formulaire2.jsp").forward(request,response);
La rponse est confie la page JSP formulaire2.jsp. Celle-ci a deux paramtres nom et age. La
servlet met ces deux valeurs dans la requte l'aide de la mthode setAttribute et la passe la page
formulaire2.jsp.
Construire la classe [ServletFormulaire2] en suivant le mme cheminement que pour la classe
[ServletFormulaire]. Une fois la compilation de la classe russie, une nouvelle classe apparat dans
[WEB-INF/classes] :
I.10.2 - La page JSP

La page JSP formulaire2.jsp est la suivante :
<%
String nom=(String)request.getAttribute("nom");
String age=(String)request.getAttribute("age");
%>
<html>
<head>
</head>
<body>
<center>
<hr>
<table>
<tr>
<td>Nom</td>
</tr>
<tr>
<td>Age</td>
</tr>
</table>
<table>
<tr>
</tr>
</table>
</form>
</center>
</body>
</html>
On voit que la page JSP commence par rcuprer les deux attributs dont elle a besoin pour s'afficher :
nom et age. Une fois qu'elle les a, la rponse au client est envoye. Construisez cette page JSP et
mettez l sous le dossier <personne> :
I.10.3 - Dploiement de l'application

Le fichier de configuration [web.xml] est modifi de la faon suivante :
DOCTYPE web-app SYSTEM "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-class>istia.st.servlets.personne.ServletFormulaire</servlet-class>
<init-param>
</init-param>
<init-param>
</init-param>
</servlet>
<servlet>
<servlet-name>formulairepersonne2</servlet-name>
<servlet-class>istia.st.servlets.personne.ServletFormulaire2</servlet-class>
<init-param>
</init-param>
<init-param>
</init-param>
</servlet>
<servlet-mapping>
<url-pattern>/formulaire</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>formulairepersonne2</servlet-name>
<url-pattern>/formulaire2</url-pattern>
</servlet-mapping>
</web-app>
Nous avons conserv l'existant et ajout :
une section <servlet> pour dfinir la nouvelle servlet ServletFormulaire2
une section <servlet-mapping> pour lui associer l'URL /formulaire2
Lancez le serveur Tomcat si besoin est. S'il tait dj actif, l'ajout de nouvelles classes ainsi que la
modification du fichier [web.xml] a du provoquer le rechargement du contexte <personne>. Nous
sommes
maintenant
prts
pour
les
tests.
Nous
demandons
l'URL
http://localhost:8080/personne/formulaire2?txtNom=milou&txtAge=10 :
Nous obtenons le mme rsultat que prcdemment mais la structure de notre application est plus
claire : une servlet qui contient de la logique applicative et dlgue une page JSP l'envoi de la
rponse au client. Nous procderons dsormais toujours de cette faon.
I.11 - Une application multi-pages

Nous allons construire une application autour du formulaire [nom, ge] prcdent. L'application sera
compose :
d'une servlet main1. C'est elle qui assurera toute la logique de l'application.
de trois pages JSP : formulaire1.personne.jsp, reponse1.personne.jsp, erreurs1.personne.jsp
Le fonctionnement de l'application est le suivant. Elle est accessible via l'URL

http://localhost:8080/personne/main1. A cette url, on obtient un formulaire fourni par la page
formulaire1.personne.jsp :
L'utilisateur remplit le formulaire et appuie sur le bouton [Envoyer] de type submit. Le bouton [Rtablir]
est de type reset, c.a.d. qu'il remet le document dans l'tat o il a t reu. Le bouton [Effacer] est de
type button. Nous verrons son rle ultrieurement. L'utilisateur doit fournir un nom et un ge valides.
Si ce n'est pas le cas, une page d'erreurs lui est envoye au moyen de la page JSP
reponse1.personne.jsp. Voici des exemples :
formulaire envoy
rponse reue
Le fichier web.xml de l'application /personne est complt par les sections suivantes :
<servlet>
<servlet-name>personne1</servlet-name>
<servlet-class>istia.st.servlets.personne.ServletPersonne1</servlet-class>
<init-param>
<param-name>urlMain</param-name>
<param-value>/personne/main1</param-value>
</init-param>
<init-param>
<param-name>urlReponse</param-name>
<param-value>/reponse1.personne.jsp</param-value>
</init-param>
<init-param>
<param-name>urlErreurs</param-name>
<param-value>/erreurs1.personne.jsp</param-value>
</init-param>
<init-param>
<param-name>urlFormulaire</param-name>
<param-value>/formulaire1.personne.jsp</param-value>
</init-param>
</servlet>
....
<servlet-mapping>
<url-pattern>/main1</url-pattern>
</servlet-mapping>
Les deux sections <servlet> et <servlet-mapping> prcdentes ne sont pas l'une la suite de l'autre.
La section <servletmapping> est avec les autres sections <servlet-mapping> derrire toutes les
sections <servlet>.
Que dit ce fichier de configuration ?
l'URL de la servlet et celles des trois pages JSP font l'objet chacune d'un paramtre de
configuration. Cela permet de changer leurs noms sans avoir recompiler l'application.
l'application appele personne1 est accessible via l'URL /main1 (servlet-mapping)
I.11.3 - Les codes

La servlet principale est la classe ServletPersonne1 suivante :
import java.util.ArrayList;
public class ServletPersonne1
extends HttpServlet {
String urlMain = null;
String urlFormulaire = null;
String urlReponse = null;
String urlErreurs = null;
ArrayList erreurs = new ArrayList();
//init

urlMain = config.getInitParameter("urlMain");
if (urlMain == null) {
erreurs.add("Le paramtre [urlMain] n'a pas t initialis");
}
urlFormulaire = config.getInitParameter("urlFormulaire");
if (urlFormulaire == null) {
erreurs.add("Le paramtre [urlFormulaire] n'a pas t initialis");
}
urlReponse = config.getInitParameter("urlReponse");
if (urlReponse == null) {
erreurs.add("Le paramtre [urlReponse] n'a pas t initialis");
}
urlErreurs = config.getInitParameter("urlErreurs");
}
/**
* @param request requte du client
* @param response rponse construire
*/
ServletException {
// on vrifie comment s'est passe l'initialisation de la servlet
if(urlErreurs==null) throw new ServletException("Le paramtre [urlErreurs] n'a pas t initialis");
if(erreurs.size()!=0){
// on passe la main la page d'erreurs
request.setAttribute("erreurs",erreurs);
getServletContext().getRequestDispatcher(urlErreurs).forward(request,response);
//fin
return;
}
// on rcupre les paramtres
// des paramtres ?
if(nom==null || age==null){
// on envoie le formulaire
request.setAttribute("nom","");
request.setAttribute("age","");
request.setAttribute("urlAction",urlMain);
getServletContext().getRequestDispatcher(urlFormulaire).forward(request,response);
return;
}//
// vrification des paramtres
ArrayList erreursAppel=new ArrayList();
nom=nom.trim();
if(nom.equals("")) erreursAppel.add("Le champ [nom] n'a pas t rempli");
if(! age.matches("^\\s*\\d+\\s*$")) erreursAppel.add("Le champ [age] est erron");
if(erreursAppel.size()!=0){
// on envoie la page d'erreurs
request.setAttribute("erreurs",erreursAppel);
return;
}//if
// les paramtres sont corrects - on envoie la page rponse
getServletContext().getRequestDispatcher(urlReponse).forward(request,response);
return;
}
/**
*/

ServletException {
}
}
La page formulaire1.personne.jsp
<%
String urlAction=(String)request.getAttribute("urlAction");
%>
<html>
<head>
</head>
<body>
<center>
<hr>
<form action="<%= urlAction %>" method="post">
<table>
<tr>
<td>Nom</td>
</tr>
<tr>
<td>Age</td>
</tr>
<tr>
</table>
<table>
<tr>
</tr>
</table>
</form>
</center>
</body>
</html>
La page reponse1.personne.jsp
<%
if(nom==null) nom="inconnu";
if(age==null) age="inconnu";
%>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Personne - rponse</h2>
<hr>
<table>
<tr>
La page reponse1.personne.jsp
<td>Nom</td>
<td><%= nom %>
</tr>
<tr>
<td>Age</td>
<td><%= age %>
</tr>
</table>
</body>
</html>
La page erreurs1.personne.jsp
<%@ page import="java.util.ArrayList" %>
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
<html>
<head>
</head>
<body>
<h2>Les erreurs suivantes se sont produites</h2>
<ul>
<%
for(int i=0;i<erreurs.size();i++){
out.println("<li>" + (String) erreurs.get(i) + "</li>\n");
}//for
%>
</ul>
</body>
</html>
Les points principaux de la servlet sont les suivants :
la mthode init de la servlet essaie de rcuprer les quatre URL du fichier de configuration
(urlMain, urlReponse, urlFormulaire, urlErreurs). Pour chacune des trois premires, si elle
choue un message d'erreur est ajout une liste d'erreurs (ArrayList). Cette liste d'erreurs sera
fournie ultrieurement la page erreurs1.personne.jsp. Si on choue rcuprer la valeur du
paramtre urlErreurs, cette variable prend la valeur null.
les mthodes doPost et doGet font la mme chose
la mthode doGet commence par vrifier s'il y a eu des erreurs l'initialisation :
elle vrifie si urlErreurs est rest null. Si oui, une exception est lance. En effet, cette
erreur ne peut tre signale normalement au client puisqu'on n'a pas de page pour
l'afficher.
si urlErreurs est non null et la liste des autres erreurs non vide alors celle-ci est affiche par
la page JSP urlErreurs.
s'il n'y a pas d'erreurs d'initialisation, doGet vrifie s'il y a les paramtres attendus (txtNom,
txtAge) dans la requte. Si ce n'est pas le cas, le formulaire est affich au moyen de la
page JSP urlFormulaire. On lui transmet un nom et un age vides ainsi que l'URL (urlAction)
laquelle devront tre renvoys les valeurs du formulaire lorsque l'utilisateur appuiera sur
le bouton [Envoyer].
s'il y a des paramtres, leur validit est vrifie au moyen d'expression rgulires. Si des
erreurs sont dtectes, leur liste est transmise la page JSP urlErreurs.
s'il n'y a pas d'erreurs, le nom et l'ge rcuprs sont transmis la page JSP urlReponse.
la mthode doGet sert aussi bien fournir le formulaire vide qu' traiter ses valeurs lorsque
l'utilisateur appuie sur le bouton [Envoyer].
Les points principaux de la page formulaire1.reponse.jsp sont les suivants :
la page reoit en atribut la valeur urlAction qui est l'URL laquelle seront envoyes les valeurs
du formulaire lorsque l'utilisateur appuiera sur le bouton [Envoyer]. urlAction pointe sur la servlet
principale. Celle-ci sert donc la fois fournir le formulaire vide et en traiter les valeurs.
Les points principaux de la page erreurs1.reponse.jsp sont les suivants :
la page reoit sous la forme d'un objet ArrayList la valeur erreurs qui est la liste des erreurs
afficher.
pour afficher celles-ci, on est amen crire du code Java dans le corps HTML de la page. On
doit toujours viser rduire celui-ci au minimum pour ne pas polluer le code HTML. Nous
verrons ultrieurement qu'il existe des solution permettant du zro Java dans les pages JSP.
I.11.4 - Dploiement
Le dploiement de l'application est celui devenu maintenant habituel :
I.11.5 - Tests
Si Tomcat tait actif lorsque vous avez fait les modifications prcdentes (classes et web.xml), il a du
recharger le contexte <personne> et le signaler dans ses logs :
7 nov. 2004 10:28:18 org.apache.catalina.startup.HostConfig restartContext
INFO: restartContext(/personne)
7 nov. 2004 10:28:18 org.apache.catalina.core.StandardContext reload
INFO: Le rechargement de ce contexte a dmarr
Au besoin, rechargez manuellement le contexte [clic droit sur projet/Projet Tomcat/Recharger le

contexte] ou relancez Tomcat. Ceci fait, on pourra reprendre les tests montrs en exemple au dbut
de cette section. On pourra en rajouter. On pourra par exemple supprimer la prsence d'un des quatre
paramtres de configuration urlXXX dans web.xml et voir le rsultat.
I.12 - Gestion d'une session

Nous nous proposons maintenant d'ajouter notre application une gestion de session. Rappelons les
points suivants :
le dialogue HTTP client-serveur est une suite de squences demande-rponse dconnectes

entre elles
la session sert de mmoire entre diffrentes squences demande-rponse d'un mme

utilisateur. S'il y a N utilisateurs, il y a N sessions.
La squence d'cran suivante montre ce qui est maintenant dsir dans le fonctionnement de
l'application :
Echange n 1
La nouveaut vient du lien de retour au formulaire qui a t rajout dans la page d'erreurs.
Echange n 2
Dans l'change n 1, l'utilisateur a donn pour le couple (nom,ge) les valeurs (xx,yy). Si au cours de
l'change, le serveur a eu connaissance de ces valeurs, la fin de l'change il les "oublie". Or on peut
constater que lors de l'change n 2 il est capable de rafficher leurs valeurs dans sa rponse. C'est
la notion de session qui permet au serveur web de mmoriser des donnes au fil des changes
successifs client-serveur. Au cours de l'change n1, le serveur doit mmoriser dans la session le
couple (nom,age) que le client lui a envoy afin d'tre capable de l'afficher au cours de l'change n 2.
Voici un autre exemple de mise en oeuvre de la session entre deux changes :
Echange n 1
La nouveaut vient du lien de retour au formulaire qui a t rajout dans la page de la rponse.
Echange n 2
Le fichier web.xml de l'application /personne est complt par les sections suivantes :
<servlet>
<init-param>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
</servlet>
....
<servlet-mapping>
</servlet-mapping>
La nouvelle application appele personne2 est accessible via l'URL /main2 (servlet-mapping)
I.12.3 - Les codes

La servlet principale est la classe ServletPersonne2. Elle ne diffre de la classe ServletPersonne1 que
par sa mthode doGet et l'ajout de l'import de la classe HttpSession :
import java.util.ArrayList;
import javax.servlet.http.HttpSession;
public class ServletPersonne2
extends HttpServlet {
...
/**
*/
ServletException {
// on vrifie comment s'est passe l'initialisation de la servlet
if(urlErreurs==null) throw new ServletException("Le paramtre [urlErreurs] n'a pas t initialis");
if(erreurs.size()!=0){
// on passe la main la page d'erreurs
request.setAttribute("erreurs",erreurs);
//fin
return;
}
// on rcupre les paramtres
// des paramtres ?
if(nom==null || age==null){
// on envoie le formulaire
request.setAttribute("urlAction",urlMain);
getServletContext().getRequestDispatcher(urlFormulaire).forward(request,response);
return;
}//
// on mmorise les deux donnes dans la session
HttpSession session=request.getSession();
session.setAttribute("nom",nom);
session.setAttribute("age",age);
// vrification des paramtres
ArrayList erreursAppel=new ArrayList();
nom=nom.trim();
if(nom.equals("")) erreursAppel.add("Le champ [nom] n'a pas t rempli");
if(! age.matches("^\\s*\\d+\\s*$")) erreursAppel.add("Le champ [age] est erron");
if(erreursAppel.size()!=0){
// on envoie la page d'erreurs
request.setAttribute("erreurs",erreursAppel);
request.setAttribute("urlRetour",urlMain);
return;
}//if
// les paramtres sont corrects - on envoie la page rponse
request.setAttribute("urlRetour",urlMain);
getServletContext().getRequestDispatcher(urlReponse).forward(request,response);
return;
}
...
Les points noter :
les paramtres [nom] et [age], s'ils existent, sont enregistrs dans la session courante. Ils y
seront disponibles pour le formulaire formulaire2.personne.jsp.
un nouvel attribut urlRetour est transmis aux pages urlErreurs et urlReponse. Il servira gnrer
le lien de retour vers le formulaire. Ce lien de retour pointe vers la servlet principale
/personne/main2. Cette servlet recevant une requte sans paramtres la transmettra au
formulaire qui lui rcuprera dans la session le couple (nom,age) s'il y a t plac auparavant.
La page formulaire2.personne.jsp est identique la page formulaire1.personne.jsp, si ce n'est qu'elle

rcupre ses paramtres [nom] et [age] dans la session plutt que dans la requte.
<%
// on rcupre les paramtres nom et age dans la session
String nom=(String)session.getAttribute("nom");
if(nom==null) nom="";
String age=(String)session.getAttribute("age");
if(age==null) age="";
// l'attribut urlAction est lui rcupr dans la requte
%>
<html>
.......
</html>
La page reponse2.personne.jsp est identique la page reponse1.personne.jsp quelques dtails

prs :
un nouvel attribut urlRetour est rcupr dans la requte
cet attribut est utilis pour gnrer le lien de bas de page
<%
String urlRetour=(String)request.getAttribute("urlRetour");
%>
<html>
<head>
</head>
<body>
<hr>
<table>
<tr>
<td>Nom</td>
<td><%= nom %>
</tr>
<tr>
<td>Age</td>
<td><%= age %>
</tr>
</table>
<br>
<a href="<%= urlRetour %>">Retour au formulaire</a>
</body>
</html>
La page erreurs2.personne.jsp est identique la page erreurs1.personne.jsp aux dtails prs suivants
:
l'attribut urlRetour est rcupr dans la requte
puis il est utilis pour gnrer le lien de bas de page
<%@ page import="java.util.ArrayList" %>

<%
%>
<html>
<head>
</head>
<body>
<ul>
<%
}//for
%>
</ul>
<br>
</body>
</html>
I.12.4 - Dploiement
I.12.5 - Tests
On pourra reproduire les tests prsents au dbut de cette nouvelle version.
I.13 - Scripts ct navigateur

I.13.1 - Le nouveau formulaire
Notre application vrifie ct serveur la validit des paramtres nom et ge du formulaire. Il doit
toujours en tre ainsi. Une application web ne doit jamais faire l'hypothse que ses clients vrifient les
donnes qu'ils lui envoient. Elle doit au contraire toujours supposer qu'on peut lui envoyer des
donnes errones parfois volontairement.
Lorsque le client est un navigateur, on peut inclure dans la page HTML qu'on envoie celui-ci des
scripts qui vrifieront les donnes envoyer au serveur avant de les envoyer rellement. Si celles-ci
s'avrent invalides, elles ne sont alors pas envoyes au serveur et les erreurs sont signales
l'utilisateur du navigateur. On a ainsi gagn un aller-retour client-serveur inutile.
Dans notre application personne la seule page JSP o il est utile de placer des scripts est celle du
formulaire. La page appele maintenant formulaire3.personne.jsp devient la suivante :
<%
String nom=(String)session.getAttribute("nom");
if(nom==null) nom="";
String age=(String)session.
if(age==null) age="";
%>
<html>
<head>
<script language="javascript">
// ------------------------------function effacer(){
// on efface les champs de saisie
with(document.frmPersonne){
txtNom.value="";
txtAge.value="";
}//with
}//effacer
// ------------------------------function envoyer(){
// vrification des paramtres avant de les envoyer
with(document.frmPersonne){
// le nom ne doit pas tre vide
champs=/^\s*$/.exec(txtNom.value);
if(champs!=null){
// le nom est vide
alert("Vous devez indiquer un nom");
txtNom.value="";
txtNom.focus();
// retour l'interface visuelle
return;
}//if
// l'ge doit tre un entier positif
champs=/^\s*\d+\s*$/.exec(txtAge.value);
if(champs==null){
// l'ge est incorrect
alert("Age incorrect");
txtAge.focus();
// retour l'interface visuelle
return;
}//if
// les paramtres sont corrects - on les envoie au serveur
submit();
}//with
}//envoyer
</script>
</head>
<body>
<center>
<hr>
<form action="<%= urlAction %>" method="post" name="frmPersonne">
<table>
<tr>
<td>Nom</td>
</tr>
<tr>
<td>Age</td>
</tr>
<tr>
</table>
<table>
<tr>
<td><input type="button" value="Envoyer" onclick="envoyer()"></td>
<td><input type="button" value="Effacer" onclick="effacer()"></td>
</tr>
</table>
</form>
</center>
</body>
</html>
Les points importants :
un nom a t donn au formulaire : <form ... name="frmPersonne">. Ce nom est utilis dans les
scripts ct navigateur
le bouton [Envoyer] autrefois de type submit est devenu de type button. Lorsqu'on clique dessus,
la fonction javascript envoyer() est appele.
de mme lorsqu'on clique sur le bouton [Effacer] lui aussi de type button, la fonction javascript
effacer() est appele.
les fonctions javascript envoyer() et effacer() ont t places entre les balises <script> et
</script> du document HTML. Le lecteur est invit lire le chapitre 9 du polycopi pour une
premire introduction Javascript et notamment ses expressions rgulires.
I.13.2 - Configuration et dploiement

Les sections suivantes sont ajoutes au fichier web.xml :
<servlet>
<init-param>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
</servlet>
.........
<servlet-mapping>
</servlet-mapping>
Les changements apports sont les suivants :
la page JSP du formuaire s'appelle dsormais formulaire3.personne.jsp.
l'application s'appelle personne3 et est disponible via l'URL /personne/main3.
Rien d'autre ne change.

On suivra la mthode de dploiement des cas prcdents pour dployer cette nouvelle application.
I.13.3 - Tests
I.14 - Utiliser des bibliothques de balises

Considrons la vue [erreurs2.personne.jsp] qui affiche une liste d'erreurs :
Il y a plusieurs faons d'crire une telle page. Nous ne nous intressons ici qu' la partie affichage des
erreurs. Une premire solution est d'utiliser du code Java comme il a t fait :
<%@ page import="java.util.ArrayList" %>0
<%
%>
<html>
<head>
</head>
<body>
<ul>
<%
}//for
%>
</ul>
<br>
</body>
</html>
La page JSP rcupre la liste des erreurs dans la requte et l'affiche l'aide d'une boucle. La page
mlange code HTML et code Java, ce qui peut tre problmatique si la page doit tre maintenue par
un infographiste qui en gnral ne comprendra pas le code Java. Pour viter ce mlange, on utilise
des bibliothques de balises qui vont apporter des possibilits nouvelles aux pages JSP. Avec la
bibliothque de balises JSTL, la vue prcdente devient la suivante :
<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<html>
<head>
</head>
<body>
<ul>
<c:forEach var="erreur" items="${erreurs}">
<li><c:out value="${erreur}"/></li>
</c:forEach>
</ul>
<br>
<a href="<c:url value="${urlRetour}"/>">Retour au formulaire</a>
</body>
</html>
La balise
signale l'utilisation d'une bibliothque de balises dont la dfinition se trouve dans le fichier
[/WEB-INF/c.tld]. Ces balises seront utilises dans le code de la page, prfixes du mot c (prefix="c").
On peut utiliser tout prfixe de son choix. Ici c signifie [core]. Les prfixes permettent d'utiliser
plusieurs bibliothques de balises qui pourraient avoir les mmes noms pour certaines balises.
L'utilisation du prfixe lve l'ambigut. La nouvelle page n'a plus de code Java. La boucle d'affichage
des erreurs a t remplace par le texte suivant :
</c:forEach>
la balise <forEach> sert dlimiter une boucle

la balise <c:out ...> sert crire une valeur
La balise <forEach> a ici deux attributs :
items="${erreurs}" indique la collection d'objets sur laquelle il faut itrer. Ici, la collection est
l'objet erreurs. O celui-ci est-il trouv ? La page JSP va chercher un attribut s'appelant "erreurs"
successivement et dans l'ordre dans :
l'objet [request] qui reprsente la requte transmise par le contrleur :

request.getAttribute("erreurs")
l'objet [session] qui reprsente la session du client : session.getAttribute("erreurs")
l'objet
[context]
qui
reprsente
le
contexte
de
l'application
web
:
context.getAttribute("erreurs")
La collection dsigne par l'attribut items peut avoir diverses formes : tableau, ArrayList, objet
implmentant l'interface List, ...
var="erreur" sert donner un nom l'lment courant de la collection en cours de traitement. La
boucle <forEach> va tre excute successivement pour chaque lment de la collection items.
A l'intrieur de la boucle, l'lment de la collection en cours de traitement sera donc dsign ici
par erreur.
La balise <c:out value="..."/> sert crire la valeur dsigne par l'attribut value. L'opration <c:out
value="${erreur}"/> insre la valeur de la variable erreur dans le texte. Cette variable n'est pas
ncessairement une chane de caractres. La balise utilise la mthode erreur.toString() pour insrer
l'objet erreur.
Pour en revenir notre exemple d'affichage des erreurs :
le contrleur mettra dans la requte transmise la page JSP un ArrayList de messages

d'erreurs, donc un ArrayList d'objets String : request.setAttribute("erreurs",erreurs) o erreurs est
le ArrayList ;
cause de l'attribut items="${erreurs}", la page JSP va chercher un attribut appel erreurs,

successivement dans la requte, la session, le contexte. Elle va le trouver dans la requte :
request.getAttribute("erreurs") va rendre le ArrayList plac dans la requte par le contrleur ;
la variable erreur de l'attribut var="erreur" va donc dsigner l'lment courant du ArrayList, donc
un objet String. La mthode erreur.toString() va insrer la valeur de ce String, ici un message
d'erreur, dans le flux HTML de la page.
Les objets de la collection traite par la balise <forEach> peuvent tre plus complexes que de simples
chanes de caractres. Prenons l'exemple d'une page JSP qui affiche une liste d'articles :
<c:forEach var="article" items="${listarticles}">
<tr>
<td><c:out value="${article.nom}"/></td>
<td><c:out value="${article.prix}"/></td>
<td><a href="<c:url value="?action=infos&id=${article.id}"/>">Infos</a></td>
</tr>
</c:forEach>
Ici, [listarticles] est un ArrayList d'objets de type [Article]. Celui-ci est un Javabean avec les champs
[id, nom, prix, stockActuel, stockMinimum]. Chacun de ces champs est accompagn de ses mthodes
get et set. L'objet [listarticles] a t plac dans la requte par le contrleur. La page JSP prcdente
va le rcuprer dans l'attribut items de la balise forEach. L'objet courant article (var="article") dsigne
donc un objet de type [Article]. Considrons la balise d'criture suivante :
<c:out value="${article.nom}"/>
Que signifie ${article.nom} ? En fait diverses choses selon la nature de l'objet article. Pour obtenir la
valeur de article.nom, la page JSP va essayer deux choses :
1
article.getNom() - on notera l'orthographe getNom pour rcuprer le champ nom (norme
Javabean)
2
article.get("nom")
On voit donc que l'objet [article] peut tre un bean avec un champ nom, ou un dictionnaire avec une
cl nom. Il n'y a pas de limites la hirarchie de l'objet trait. Ainsi la balise
<c:out value="${individu.enfants[1].nom}"/>
permet de traiter un objet [individu] de type suivant :
class Individu{
private String nom;
private String prnom;
private Individu[] enfants;
// mthodes de la norme Javabean
public String getNom(){ return nom;}
public String getPrnom(){ return prnom;}
public Individu getEnfants(int i){ return enfants[i];}
}
Pour obtenir la valeur de ${individu.enfants[1].nom}, la page JSP va essayer diverses mthodes dont
celle-ci qui russira : individu.getEnfants(1).getNom() o individu dsigne un objet de type Individu.
La page JSP d'erreurs utilise une balise JSTL galement pour afficher le lien de retour vers le
formulaire de l'application :
Si [/personne] est le contexte de l'application et [main3] la valeur de la variable [urlRetour], le texte

HTML gnr par le code cidessus sera le suivant :
<a href="/personne/main3"/>">Retour au formulaire</a>
La balise <c:url ..> prfixe toute url par le contexte de l'application, ici [/personne]. Cela permet de
grer des url indpendamment du contexte. C'est important car le nom d'un contexte peut tre amen
changer.
L'utilisation de la bibliothque de balises JSTL dans les vues JSP de notre application ncessite :
la prsence du fichier c.tld dans l'arborescence de l'application web. Ici, nous l'avons plac dans
le dossier [WEBINF] :
la prsence des archives des classes utilises par la bibliothque JSTL : jstl.jar et standard.jar.
Ces deux archives sont places dans [WEB-INF/lib] :
la prsence de la directive suivante dans toutes les pages JSP utilisant la bibliothque :
Une nouvelle application utilisant la bibliothque JSTL dans les vues amne les modifications
suivantes :
web.xml
<servlet>
<init-param>
<param-value>/main4</param-value>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
<init-param>
</init-param>
</servlet>
...
<servlet-mapping>
</servlet-mapping>
En-dehors des noms d'url qui changent, la princiaple diffrence vient de la valeur du paramtre
[urlMain]. Celle-ci ne contient plus le nom du contexte /personne, ceci grce l'utilisation de la balise
JSTL <c:url ...> dans les vues.
Vue formulaire4.personne.jsp
<html>
<head>
<script language="javascript">
.... (idem version prcdente)
</script>
</head>
<body>
<center>
<hr>
<form method="post" name="frmPersonne" action="<c:url value="${urlAction}"/>">
<table>
<tr>
<td>Nom</td>
<td><input name="txtNom" value="<c:out value="${nom}"/>" type="text" size="20"></td>
</tr>
<tr>
Vue formulaire4.personne.jsp
<td>Age</td>
<td><input name="txtAge" value="<c:out value="${age}"/>" type="text" size="3"></td>
</tr>
<tr>
</table>
<table>
<tr>
<td><input type="submit" value="Submit"></td>
<td><input type="button" value="Envoyer" onclick="envoyer()"></td>
<td><input type="button" value="Effacer" onclick="effacer()"></td>
</tr>
</table>
</form>
</center>
</body>
</html>
Nous avons rajout un bouton de type [submit] au formulaire afin de pouvoir court-circuiter la
vrification des donnes faites par le navigateur lors de l'utilisation du bouton [Envoyer] et d'avoir ainsi
accs la page [erreurs4.personne.jsp].
Vue reponse4.personne.jsp
<html>
<head>
</head>
<body>
<hr>
<table>
<tr>
<td>Nom</td>
<td><c:out value="${nom}"/></td>
</tr>
<tr>
<td>Age</td>
<td><c:out value="${age}"/></td
</tr>
</table>
<br>
Vue reponse4.personne.jsp
</body>
</html>
Vue erreurs4.personne.jsp
<html>
<head>
</head>
<body>
<ul>
</c:forEach>
</ul>
<br>
</body>
</html>
Dploiement
I.15 - Crer une page d'accueil

Lorsque nous demandons l'url [http://localhost:8080/personne/], nous obtenons actuellement le
rsultat suivant (vue partielle) :i
Nous obtenons le contenu du dossier de l'aplication. Ce n'est pas une bonne chose. Ici, un internaute
peut obtenir le contenu du fichier [erreurs1.personne.jsp] et de faon gnrale de tous les fichiers qui
seront exposs dans la vue ci-dessus. Il est possible d'viter cela au moins de deux faons :
configurer Tomcat pour qu'il n'affiche pas le contenu du dossier
faire en sorte que lorsque le contexte est demand, on affiche une page dite d'accueil plutt que
la liste ci-dessus.
Nous dveloppons ici la deuxime solution. On ajoute au fichier [web.xml] une nouvelle balise :
.....
<welcome-file-list>
<welcome-file>/index.jsp</welcome-file>
</welcome-file-list>
</web-app>
La balise <welcome-file-list> sert dfinir la liste des vues prsenter lorsqu'un client demande le
contexte de l'application. Il peut y avoir plusieurs vues. La premire trouve est prsente au client. Ici
nous n'en avons qu'une [index.jsp]. Celle-ci se contente de redirger le client vers une autre URL :
<c:redirect url="/main4"/>
La redirection se fait au moyen de la balise JSTL <c:redirect .../>. Le lecteur est invit tester cette
nouvelle version lui-mme car ici les copies d'cran ne peuvent montrer la redirection l'oeuvre.
I.16 - Dveloppement MVC

Dans le dveloppement logiciel en gnral et dans le dveloppement web en particulier, on cherche
sparer nettement les couches prsentation, traitement et accs aux donnes. L'architecture d'une
application web est ainsi souvent la suivante :
Une telle architecture, appele 3-tiers ou 3 niveaux cherche respecter le modle MVC (Model
View Controller) :
l'interface utilisateur contient le V (la vue) et le C (le contrleur)
les couches mtier et d'accs aux donnes forment le M (Modle)
Pour une architecture web J2EE, le schma trois couches peut tre dtaill de la faon suivante :
L'interface utilisateur est ici un navigateur web mais cela pourrait tre galement une application
autonome qui via le rseau enverrait des requtes HTTP au service web et mettrait en forme les
rsultats que celui-ci lui envoie. La logique applicative est constitue des scripts traitant les demandes
de l'utilisateur, ici la servlet Java. La source de donnes est souvent une base de donnes mais cela
peut tre aussi un annuaire LDAP ou un service web distant. Dans les exemples dvelopps
prcdemment, il n'y avait que la seule couche [Interface utilisateur].
Le dveloppeur a intrt maintenir une grande indpendance entre ces trois entits afin que si l'une
d'elles change, les deux autres n'aient pas changer ou peu.
On mettra la logique mtier de l'application dans des classes Java spares de la servlet qui
contrle le dialogue demanderponse. Ainsi le bloc [Logique applicative] ci-dessus sera
constitu des lments suivants :
Dans le bloc [Logique Applicative], on pourra distinguer
le bloc [IE=Interface d'Entre] qui est la porte d'entre de l'application. Elle est la mme quelque
soit le type de client.
le bloc [Classes mtier] qui regroupe des classes Java ncessaires la logique de l'application.
Elles sont indpendantes du client.
le bloc des gnrateurs des pages rponse [IS1 IS2 ... IS=Interface de Sortie]. Chaque
gnrateur est charg de mettre en forme les rsultats fournis par la logique applicative pour un
type de client donn : code HTML pour un navigateur ou un tlphone WAP, code XML pour une
application autonome, ... Ce modle assure une bonne indpendance vis vis des clients. Que
le client change ou qu'on veuille faire voluer sa faon de prsenter les rsultats, ce sont les
gnrateurs de sortie [IS] qu'il faudra crer ou adapter.
Dans une application web, l'indpendance entre la couche prsentation et la couche traitement
peut tre amliore par l'utilisation de feuilles de style. Celles-ci gouvernent la prsentation d'une
page Web au sein d'un navigateur. Pour changer cette prsentation, il suffit de changer la feuille
de style associe. Il n'y a pas toucher la logique de traitement.
Dans le diagramme ci-dessus, les classes mtier passent par des classes intermdiaires pour
accder aux donnes. Ainsi les classes mtier forment le noyau dur de l'application insensible
aux changements de prsentation ou d'accs aux donnes.
Dans les cas simples, la logique applicative est souvent rduite deux classes :
la servlet assurant le dialogue client-serveur : traitement de la requte, gnration des diverses

rponses
la classe mtier qui reoit de la servlet des donnes traiter et lui fournit en retour des rsultats.
I.16.2 - Une dmarche de dveloppement MVC en Java!

Nous proposons ici une dmarche possible pour le dveloppement d'applications web java selon le
modle MVC prcdent :
on commencera par dfinir toutes les vues de l'application. Celles-ci sont les pages Web
prsentes l'utilisateur. On se placera donc du point de vue de celui-ci pour dessiner les vues.
On distingue trois types de vues :
le formulaire de saisie qui vise obtenir des informations de l'utilisateur. Celui-ci dispose en
gnral d'un bouton pour envoyer les informations saisies au serveur.
la page de rponse qui ne sert qu' donner de l'information l'utilisateur. Celle-ci dispose
souvent d'un lien permettant l'utilisateur de poursuivre l'application avec une autre page.
la page mixte : la servlet a envoy au client une page contenant des informations qu'elle a
gnres. Cette mme page va servir au client pour fournir la servlet d'autres
informations.
Chaque vue donnera naissance une page JSP. Pour chacune de celles-ci :
on dessinera l'aspect de la page
on dterminera quelles sont les parties dynamiques de celle-ci :
les informations destination de l'utilisateur qui devront tre fournies par la servlet en
paramtres la vue JSP
les donnes de saisie qui devront tre transmises la servlet pour traitement.
Celles-ci devront faire partie d'un formulaire HTML.
On pourra schmatiser les E/S de chaque vue
les entres sont les donnes que devra fournir la servlet la page JSP soit dans la requte
(request) ou la session (session).
les sorties sont les donnes que devra fournir la page JSP la servlet. Elles font partie d'un
formulaire HTML et la servlet les rcuprera par une opration du type
request.getparameter(...).
On crira le code Java/JSP de chaque vue. Il aura le plus souvent la forme suivante :
<%@ page ... %> // importations de classes le plus souvent
<%!
// variables d'instance de la page JSP (=globales)
// ncessaire que si la page JSP a des mthodes partageant des variables (rare)
...
%>
<%
// rcupration des donnes envoyes par la servlet
// soit dans la requte (request) soit dans la session (session)
...
%>
<html>
...
// on cherchera ici minimiser le code java
</html>
On peut alors passer aux premiers tests. La mthode de dploiement explique ci-dessous est
propre au serveur Tomcat :
le contexte de l'application doit tre cr dans le fichier server.xml de Tomcat. On pourra

commencer par tester ce contexte. Soit C ce contexte et DC le dossier associ celui-ci.
On construira un fichier statique test.html qu'on placera dans le dossier DC. Aprs avoir
lanc Tomcat, on demandera avec un navigateur l'URL http://localhost:8080/C/test.html.
chaque page JSP peut tre teste. Si une page JSP s'appelle formulaire.jsp, on
demandera avec un navigateur l'URL http://localhost:8080/C/formulaire.jsp. La page JSP
attend des valeurs de la servlet qui l'appelle. Ici on l'appelle directement donc elle ne
recevra pas les paramtres attendus. Afin que les tests soient nanmoins possibles on
initialisera soi-mme dans la page JSP les paramtres attendus avec des constantes. Ces
premiers tests permettent de vrifier que les pages JSP sont syntaxiquement correctes.
On crit ensuite le code de la servlet. Celle-ci a deux mthodes bien distinctes :
la mthode init qui sert :
rcuprer les paramtres de configuration de l'application dans le fichier web.xml de

celle-ci
ventuellement crer des instances de classes mtier qu'elle sera amene utiliser
ensuite
grer une ventuelle liste d'erreurs d'initialisation qui sera renvoye aux futurs
utilisateurs de l'application. Cette gestion d'erreurs peut aller jusqu' l'envoi d'un ml
l'administrateur de l'application afin de le prvenir d'un dysfonctionnement
la mthode doGet ou doPost selon la faon dont la servlet reoit ses paramtres de ses
clients. Si la servlet gre plusieurs formulaires, il est bon que chacun d'entre-eux envoie
une information qui l'identifie de faon unique. Cela peut se faire au moyen d'un attribut
cach dans le formulaire du type <input type="hidden" name="action" value="...">. La
servlet peut commencer par lire la valeur de ce paramtre puis dlguer le traitement de la
requte une mthode prive interne charge de traiter ce type de requte.
On vitera au maximum de mettre du code mtier dans la servlet. Elle n'est pas faite pour
cela. La servlet est une sorte de chef d'quipe (contrleur) qui reoit des demandes de ses
clients (clients web) et qui les fait excuter par les personnes les plus appropries (les
classes mtier). Lors de l'criture de la servlet, on dterminera l'interface des classes

mtier crire (constructeurs, mthodes). Cela si ces classes mtier sont construire. Si
elles existent dj, alors la servlet doit s'adapter l'interface existante.
le code de la servlet sera compil.
On crira le squelette des classes mtier ncessaires la servlet. Par exemple, si la servlet
utilise un objet de type proxyArticles et que cette classe doit avoir une mthode getCodes
rendant une liste (ArrayList) de chanes de caractres, on peut se contenter dans un premier
temps d'crire :
public ArrayList getCodes(){
String[] codes= {"code1","code2","code3"};
ArrayList aCodes=new ArrayList();
for(int i=0;i<codes.length;i++){
aCodes.add(codes[i]);
}
return aCodes;
}
On peut alors passer aux tests de la servlet.
le fichier de configuration web.xml de l'application doit tre cr. Il doit contenir toutes les
informations attendues par la mthode init de la servlet (<init-param>). Par ailleurs, on fixe
l'URL au travers de laquelle sera atteinte la servlet principale (<servlet-mapping>).
toutes les classes ncessaires (servlet, classes mtier) sont places dans
WEB-INF/classes.
toutes les bibliothques de classes (.jar) ncesaires sont places dans WEB-INF/lib. Ces
bibliothques peuvent contenir des classes mtier, des pilotes JDBC, ....
les vues JSP sont places sous la racine de l'application ou un dossier propre. On fait de
mme pour les autres ressources (html, images, son, vidos, ...)
ceci fait, l'application est teste et les premires erreurs corriges. A la fin de cette phase,
l'architecture de l'application est oprationnelle. Cette phase de test peut tre dlicate
sachant qu'on n'a pas d'outil de dbogage avec Tomcat. Il faudrait pour cela que Tomcat
soit lui-mme intgr dans un outil de dveloppement (Jbuilder Developer, Sun One
Studio, ...). On pourra s'aider d'instructions System.out.println("....") qui crivent dans la
fentre de Tomcat. La premire chose vrifier est que la mthode init rcupre bien
toutes les donnes provenant du fichier web.xml. On pourra pour cela crire la valeur de
celles-ci dans la fentre de Tomcat. On vrifiera de la mme faon que les mthodes
doGet et doPost rcuprent correctement les paramtres des diffrents formulaires HTML
de l'application.
On crit les classes mtier dont a besoin la servlet. On a l en gnral le dveloppement

classique d'une classe Java le plus souvent indpendante de toute application web. Elle sera
tout d'abord teste en dehors de cet environnement avec une application console par exemple.
Lorsqu'une classe mtier a t crite, on peut l'intgrer dans l'architecture de dploiement de
l'application web et tester sa correcte intgration dans celui-ci. On procdera ainsi pour chaque
classe mtier.
I.16.3 - Pour approfondir le dveloppement web MVC

Struts - c'est l'outil le plus connu. La plupart des dveloppements MVC en java sont faits
actuellement avec la dmarche et les bibliothques Struts.
Spring - c'est un outil plus rcent qui ne se limite pas au dveloppement MVC. Son intrt
principal est qu'il apporte une aide dans les trois couches [web - mtier - dao], du
dveloppement web. Struts lui se cantonne la seule couche web.
I.16.4 - Tlchargements
Article au format HTML/ZIP
Article au format PDF Article au format PDF (version originale)

Java Eclipse Tomcat

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Java Eclipse Tomcat

Transféré par

Droits d'auteur :

Formats disponibles

Dveloppement web en Java avec Eclipse et

Ce document est un tutoriel de dveloppement web en Java avec les outils

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.2 - Les outils

le serveur web TOMCAT (http://jakarta.apache.org/tomcat/),

XmlBuddy pour grer les documents XML (http://xmlbuddy.com/)

Tomcat de Sysdeo (http://www.sysdeo.com/eclipse/tomcatPlugin.html) pour grer Tomcat

un navigateur (IE, NETSCAPE, MOZILLA, OPERA, ...) :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.3 - Le conteneur de servlets Tomcat 5

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Ici JAVA_HOME dsigne un JDK de Sun dont l'arborescence est la suivante :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Le moniteur de Tomcat est activ par un double-clic sur cette icne :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.4 - Dploiement d'une application web au sein du serveur Tomcat

L'application web est configure par un fichier XML : <webapp>\WEB-INF\web.xml.

dont le contenu est le suivant :@

Si on charge ce fichier dans un navigateur, on obtient la page suivante :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Cette page permet l'administrateur de Tomcat de dfinir

des sources de donnes (Data Sources),

Suivons le lien [Roles] ci-dessus :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

dont le contenu est le suivant :@

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

rle peut utiliser ce lien :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Pour obtenir le fichier [D:\data\serge\devel\web\servlets\exemple\vues\exemple.html], nous

et la nouvelle application apparat dans la liste des applications dployes :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Commentons la ligne du contexte /exemple ci-dessus :

Le dploiement a eu pour effet d'ajouter un nouveau descripteur XML dans le dossier

Le fichier exemple.xml dcrit l'application web ajoute :

crire la main le descripteur XML de l'application dployer

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

d'abord, nous demandons l'url racine du contexte http://localhost:8080/exemple/ :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.5 - Installation de plugins Eclipse

Nous obtenons un zip dont la structure (partielle) est la suivante :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

la version de Tomcat installe sur le poste

XmlBuddy pour la gestion des documents Xml (http://xmlbuddy.com/)

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.6 - Lancer-Arrter Tomcat depuis Eclipse

De gauche droite : Lancer Tomcat - Arrter Tomcat - Relancer Tomcat (Arrt+Redmarrage)

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

[WEB-INF/classes] et [WEB-INF/lib]. Il faut en gnral vrifier la prsence des classes

Pour vrifier la prsence de Tomcat, prenez un navigateur et demandez l'url [http://localhost:8080] :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

I.7 - Dveloppement d'une application web avec Eclipse/Tomcat

que nous dfinissons comme un projet Tomcat :

Dveloppement web en Java avec Eclipse et Tomcat par Serge Tah

La seconde page de l'assistant nous demande de dfinir le contexte [3] de l'application :