> Le Site du Zéro - Informatique

> Cours

> Tutoriels

> Programmation

> Java

> Apprenez à créer des applications web dynamiques avec JEE

> Prologue : les bases

> Les servlets : premier opus

> Lecture du tutoriel

Les servlets : premier opus

Par

cysboy

Mise à jour : 24/07/2009

Difficulté : Difficile

10 160 visites depuis 7 jours, dont 1 198 sur ce chapitre classé 25/786

Enfin, nous allons commencer à faire du Java !
Vous attendiez ce moment avec impatience mais vous allez peut-être le regretter... :diable:

Je plaisante bien sûr.

Nous allons tout prendre à partir de Zéro, c'est rassurant.

Tout d'abord, sachez qu'une servlet est une classe Java comme vous en avez fait des centaines de fois (si ce n'est pas des milliers...). La différence majeure réside dans le fait qu'elle a un rôle à jouer dans le jeu JEE !

Retour en haut

Sommaire du chapitre :

Hello world
Expliquons tout ça
Une question de contexte
Q.C.M.

Retour en haut

Hello world

À partir de maintenant, je pars du principe que vous savez comment déployer, démarrer, arrêter et consulter une application !

Avant toute chose, vous allez avoir besoin d'un autre plug-in pour Eclipse : le plugin XML Buddy.
Celui-ci vous permettra de vous simplifier la vie lorsque vous allez créer des fichier XML (oui, oui, vous allez en faire). Je vous laisse le soin de le télécharger et de décompresser l'archive dans le dossier plugin d'Eclipse.
Si vous êtes perdus, une simple recherche de ce plug-in sur Google vous donnera satisfaction !

Nous allons commencer par un simple "hello world" et je vous assure que rien qu'avec ceci, il y a du travail et plein de choses à voir !

Comme je vous l'avais dit, une servlet est une classe Java que Tomcat va utiliser.
Je vous invite donc à créer une nouvelle classe Java dans le dossier WEB-INF/src de votre projet Tomcat :

Faîtes un clic droit sur ce dossier dans Eclipse et choisissez "new > Class", nommez-la DoIt dans le package com.servlet.test , voyez ci-dessous :

Vous vous retrouvez avec une classe ayant un code minimal.
Je vous informe maintenant qu'une servlet digne de ce nom DOIT hériter d'une classe qui s'appelle HttpServlet, classe qui se trouve dans le package javax.servlet.http.HttpServlet . Vous vous retrouvez donc avec ce code :

Code : Java

package com.servlet.test;
import javax.servlet.http.HttpServlet;

public class DoIt extends HttpServlet{

}

Nous allons faire en sorte que notre servlet puisse être appelée à la place de notre fichier index.html
À partir de maintenant, je vous demande de bien vouloir me faire confiance et de partir du principe que la lumière sera faite sur ce qui va suivre.

Vous allez compléter le code de votre servlet comme ceci :

Code : Java

package com.servlet.test;
import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class DoIt extends HttpServlet {

	public void doGet(HttpServletRequest request, HttpServletResponse response)
		throws IOException, ServletException{
		
		response.setContentType("text/html");
		PrintWriter out = response.getWriter();
		out.println("<h1>Coucou toi !</h1>");
	}	
}

Ne prenez pas peur à cause de tous ces imports...

Maintenant, nous allons créer un fichier xml qui DOIT s'appeler web.xml et que vous créerez dans le dossier WEB-INF de votre projet, comme ceci :

Pour faire ceci, faites un clic droit sur le dossier WEB-INF, choisissez new > XML Document et appelez-le web.xml.
Vous allez poursuivre en y ajoutant ce contenu :

Code : XML

<web-app>

	<servlet>
		<servlet-class>com.servlet.test.DoIt</servlet-class>
		<servlet-name>firstServlet</servlet-name>
	</servlet>
	
	<servlet-mapping>
		<servlet-name>firstServlet</servlet-name>
		<url-pattern>/</url-pattern>
	</servlet-mapping>

</web-app>

Faites-moi confiance...

Maintenant, retournez sur la page d'administration de Tomcat, et sur votre page, vous devriez dorénavant avoir ceci :

Vous venez de faire votre première servlet fonctionnelle !
Maintenant, je peux vous expliquer ce que nous avons fait.

Retour en haut

Expliquons tout ça

Vous devez avoir 10 000 questions à me poser et je compte bien y répondre !
Tout d'abord, afin que vous compreniez mieux la façon dont tout ceci fonctionne, vous devez savoir pourquoi on appelle Tomcat un conteneur de servlet.

Vous vous souvenez que le web fonctionne avec un système de questions - réponses (requêtes HTTP, réponses HTTP) et que, lorsque vous demandez une page web, vous envoyez une requête de type GET.
Les Zéros se souvenant de ces points ont très certainement remarqué que la méthode déclarée dans notre servlet contient le nom du type de requête envoyée : requête de type GET - méthode doGet .
Un autre point troublant : la méthode doGet de notre servlet prend deux objets en paramètres et ceux-ci ont des noms qui ressemblent beaucoup à requête HTTP et réponse HTTP !

Est-ce que ça veut dire que notre servlet reçoit la requête HTTP et retourne la réponse HTTP ?

Vous y êtes presque...

En fait, ce n'est pas la servlet qui reçoit tout ceci directement : c'est Tomcat !
C'est le conteneur de servlets qui reçoit et envoie les requêtes HTTP... Dès que ce dernier reçoit une requête, il instancie deux objets :

un objet HttpServletRequest contenant les informations de la requête HTTP ;
un objet HttpServletResponse, servant à fournir la réponse attendue.

Une fois ceci fait, il va utiliser la servlet correspondant à la requête demandée et va invoquer la méthode adéquate, ici doGet(HttpServletRequest request, HttpServletResponse response) !

La méthode adéquate ? Tu veux dire qu'il peux y avoir plusieurs méthodes dans une servlet ?

Vous avez vu juste !
Pour faire court, il y existe une méthode pour chaque type de requête HTTP :

GET : méthode doGet() , c' est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet ;
POST : méthode doPost() , cette méthode doit être utilisée lorsqu'une requête modifie la ressource ;
HEAD : méthode doHead() , cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même ;
OPTIONS : méthode doOptions() , cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général ;
CONNECT : méthode doConnect() , cette méthode permet d'utiliser un proxy comme un tunnel de communication ;
TRACE : méthode doTrace() , cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et d'effectuer un diagnostic sur la connexion ;
PUT : méthode doPut() , cette méthode permet d'ajouter une ressource sur le serveur ;
DELETE : méthode doDelete() , cette méthode permet de supprimer une ressource du serveur.

Je n'ai pas inventé ces définitions, celles-ci sont tirées de Wikipédia...

Pas de panique, dans 99.99999999 % des cas, vous utiliserez des requêtes de type GET ou POST !

Attends deux minutes ! Quand doit-on utiliser tel ou tel type de requête ?

Nous reviendrons sur ce point très bientôt. Pour le moment, essayez de comprendre comment fonctionne Tomcat lorsqu'il reçoit des requêtes HTTP.

Reprenons. Dans les grandes lignes, Tomcat reçoit une requête HTTP d'un certain type, il utilise un objet requête et un objet réponse, il instancie la servlet correspondante à la requête et invoque la méthode adéquate.
Le contenu de ladite méthode est exécuté, Tomcat récupère les objets et nous retourne la réponse HTTP ! Voici un schéma récapitulatif :

Ensuite, le contenu de la servlet est très simple :

response.setContentType("text/html") : définit le type de réponse, ici, on retourne une page HTML ;
PrintWriter out = response.getWriter() : on récupère un objet permettant d'écrire dans la future page HTML ;
out.println("....") : écrit dans la page.

Les plus observateurs d'entre vous ont dû remarquer qu'une servlet n'a pas de constructeur !
Ne vous alarmez pas sur ce point pour le moment, nous aurons l'occasion d'y revenir.

D'accord, on a compris. Par contre, comment Tomcat sait quelle servlet instancier ?

Avec le dernier point à éclaircir pour le moment : le fichier web.xml.
Vous avez compris ce qu'il se passe lorsque une requête HTTP est reçue par Tomcat.
Avant tout ceci, il se passe quelque chose de vital : le mapping des servlets !

Au lancement du serveur Tomcat, vous pouvez voir tout plein de choses incompréhensibles dans la console d'Eclipse, en voici une partie :

Et quelque part dans tout ce charabia, il y a ceci :

Ici on voit qu'une chose obscure nommée "contexte" a été initialisée !
Ceci est tout simplement une sorte d'annuaire pour Tomcat : la définition des applications sur le serveur ainsi que la structure de celles-ci.

Retour en haut

Une question de contexte

Chaque application sur le serveur a une structure et cette structure est définie dans le fichier web.xml.
Ce fichier est utilisé par Tomcat pour faire une relation entre une requête HTTP et une servlet.
On dit aussi que le fichier sert à définir le contexte de votre application.

Un seul fichier web.xml par application !

Vous avez dû avoir peur de ce fichier, mais il n'y a pas de quoi, je vous assure...

Nous allons voir comment ce fichier est construit et à quoi correspond tout ceci... Tout d'abord, vous avez sûrement vu que le contenu est englobé par une balise :

Code : XML

<web-app>
...
...
...
</web-app>

Cet encadrement, bien qu'incomplet, est OBLIGATOIRE.

Incomplet ?

Oui, il manque des informations à cette balise, mais nous les ajouterons plus tard. Le but étant toujours de comprendre le fonctionnement de Tomcat.

Donc, tout fichier web.xml doit être défini de la sorte ! Ensuite, nous trouvons deux éléments de même rang : par là, entendez balises xml se suivant et étant non imbriquées. Voici un schéma :

Chaque couleur correspond à un niveau dans le fichier xml.
Vous m'avez compis, les éléments de même rang sont <servlet></servlet> et <servlet-mapping></servlet-mapping> .
Dans ces éléments, nous allons définir les noms de notre servlet !

Tu veux dire que notre servlet a plusieurs noms ?

Tout à fait. En fait, notre servlet a :

son nom, le nom de la classe complet avec le package ;
un nom de mappage interne à l'application, nom que la servlet porte dans l'application ;
nom de la servlet pour le client.

La servlet est tout d'abord définie dans l'application via l'élément <servlet></servlet> . Nous trouvons deux éléments dans ce dernier :

<servlet-class></servlet-class> : code réel de la servlet ;
<servlet-name></servlet-name> : nom interne à l'application.

Ensuite, nous trouvons <servlet-mapping></servlet-mapping> contenant les informations de paramétrage client :

<servlet-name></servlet-name> : nom interne à l'application ;
<url-pattern></url-pattern> : nom qui apparaît côté client.

Voici un petit récapitulatif de ce qu'il se passe.

1/ Tomcat, à son lancement, prend connaissance des données mentionnées dans le fichier de configuration.
2/ Il reçoit une requête HTTP demandant "/", dans notre cas bien sûr.
3/ Il sait que ce nom est associé au nom de servlet "FirstServlet" qui, lui, correspond à la servlet com.servlet.test.DoIt .
4/ Celle-ci est instanciée et la méthode adéquate est invoquée.
5/ La réponse est récupérée par Tomcat qui renvoie cette dernière au client.

Un petit schéma (les instanciations des objets requêtes et réponses sont tacites) :

Pourquoi avoir autant de noms pour une servlet ?

Tout simplement pour faciliter les changements éventuels. Une chose importante à savoir : une servlet peut être utilisée pour faire plusieurs choses... Nous allons y venir.

Imaginez que vous appeliez votre servlet depuis une vingtaine de pages et que vous utilisiez le nom réel de votre servlet... Déjà, les utilisateurs connaîtront la hiérarchie de vos classes, et tous ceux qui ont déjà fait des sites web savent qu'il vaut mieux que le client en sache le moins possible.
Ensuite, si vous avez changé le nom de votre servlet, vous allez avoir 20 pages à reprendre une par une pour faire les changement alors que là, tout est automatique ! :magicien:

Vous pouvez changer le nom de votre servlet, ce n'est pas grave puisque nous utilisons un autre nom.

Vous avez appris beaucoup de choses dans ce chapitre. Le temps est venu de faire une pause et d'aller faire un tour sur le QCM...

Retour en haut

Votre première servlet est au point maintenant et vous êtes toujours en vie !
Mais ne vous leurrez pas, on ne s'arrête pas là. La plateforme JEE offre bien d'autres outils à utiliser.
De plus, je vous avais dit, au début de ce tutoriel, que les servlets fonctionnent avec ce qu'on appelle des JSP.
Si vous voulez savoir ce qu'il en est, rendez-vous au chapitre suivant !

Retour en haut

Retour en haut

24 commentaires pour "Les servlets : premier opus"

Note moyenne : 3.17 / 4 (294 votes)

Pseudo	Commentaire
parata	# Posté le 09/10/2011 à 15:49:33
Blog Twitter close	Bonjour, Le lien que tu donnes pour télécharger le plugin XML Buddy est un installateur .exe pour décompresser ce plugin. Mais moi je suis sur Mac donc savez-vous où je peux télécharger uniquement ce plugin. J'ai déjà fait de nombreuses recherches sur le net mais sans résultat. Donc si vous avez le plugin, il serait sympa de la partager pour tous ou m'envoyer un MP pour que je donne mon email pour ainsi faire le partage Merci d'avance Rencontre amoureuse Flirt Rencontre Tchat et loisir et Chatroulette
lutin2706_	# Posté le 20/10/2011 à 16:30:40
On est maître de son destin Blog Twitter close	Parata, des nouvelles ? Moi, je suis sous Ubuntu, et idem. Pas de .exe ici non plus ... Séverine
parata	# Posté le 28/12/2011 à 21:35:41
Blog Twitter close	Citation : lutin2706_ Parata, des nouvelles ? Moi, je suis sous Ubuntu, et idem. Pas de .exe ici non plus ... Non lutin, toujours rien Rencontre amoureuse Flirt Rencontre Tchat et loisir et Chatroulette
pef2012	# Posté le 04/01/2012 à 22:14:27
	Comment ça se fait que dans une servlet on utilise throws sans passer par trow new ?
moezlove	# Posté le 02/02/2012 à 21:33:20
	salut cysboy mr6 pour votre tuto c est vraiment superbe mé jai un prb ce que lorsque je vé créé une class DoIt eclipse m affiche package com.servlet.test; public class DoIt { } dc j ajoute les bilio necessaire mé lors de laffichage de hellow word jai que salut le zero (celui de index.html) nn coucou tous dc svp aider moi