Nous venons de créer un fichier de configuration pour notre application, nous devons donc redémarrer notre serveur pour que ces modifications soient prises en compte. Il suffit pour cela de cliquer sur le bouton "start" de l'onglet Servers, comme indiqué à la figure suivante.
Bouton de
redémarrage du serveur Tomcat dans Eclipse
Faisons le test, et observons ce que nous affiche notre navigateur lorsque nous tentons d'accéder à l'URL
http://localhost:8080/test/toto que nous venons de mapper sur notre servlet (voir la figure suivante).
Méthode HTTP non supportée
Nous voici devant notre premier code de statut HTTP. En l'occurrence, c'est à la fois une bonne et une mauvaise nouvelle : une bonne nouvelle, car cela signifie que notre mapping a fonctionné et que notre serveur a bien contacté notre servlet ! une mauvaise nouvelle, car notre serveur nous retourne le code d'erreur 405 et nous précise que la méthode GET n'est pas supportée par la servlet que nous avons associée à l'URL…
Par qui a été générée cette page d'erreur ?
Tout est parti du conteneur de servlets. D'ailleurs, ce dernier effectue pas mal de choses dans l'ombre, sans vous le dire ! Dans ce cas précis, il a :
1. reçu la requête HTTP depuis le serveur web ; 2. généré un couple d'objets requête/réponse ;
3. parcouru le fichier web.xml de votre application à la recherche d'une entrée correspondant à l'URL contenue dans l'objet requête ;
4. trouvé et identifié la servlet que vous y avez déclarée ;
5. contacté votre servlet et transmis la paire d'objets requête/réponse.
Dans ce cas, pourquoi cette page d'erreur a-t-elle été générée ?
Nous avons pourtant bien fait hériter notre servlet de la classe HttpServlet, notre servlet doit pouvoir interagir avec HTTP ! Qu'est-ce qui cloche ? Eh bien nous avons oublié une chose importante : afin que notre servlet soit capable de traiter une requête HTTP de type GET, il faut y implémenter une méthode… doGet() ! Souvenez-vous, je vous ai déjà expliqué que la méthode service() de la classe HttpServlet s'occupera alors elle-même de transmettre la requête GET entrante vers la méthode doGet() de notre servlet… Ça vous revient ?
Maintenant, comment cette page d'erreur a-t-elle été générée ?
C'est la méthode doGet() de la classe mère HttpServlet qui est en la cause. Ou plutôt, disons que c'est grâce à elle ! En effet, le comportement par défaut des méthodes doXXX() de la classe HttpServlet est de renvoyer un code d'erreur HTTP 405 ! Donc si le développeur a bien fait son travail, pas de problème : c'est bien la méthode doXXX() de la servlet qui sera appelée. Par contre, s'il a mal fait son travail et a oublié de surcharger la méthode doXXX() voulue, alors c'est la méthode de la classe mère HttpServlet qui sera appelée, et un code d'erreur sera gentiment et automatiquement renvoyé au client. Ainsi, la classe mère s'assure toujours que sa classe fille - votre servlet ! - surcharge bien la méthode doXXX() correspondant à la méthode HTTP traitée !
Par ailleurs, votre conteneur de servlets est également capable de générer lui-même des codes d'erreur HTTP. Par exemple, lorsqu'il parcourt le fichier web.xml de votre application à la recherche d'une entrée correspondant à l'URL envoyée par le client, et qu'il ne trouve rien, c'est lui qui va se charger de générer le fameux code d'erreur 404 !
Nous voilà maintenant au courant de ce qu'il nous reste à faire : il nous suffit de surcharger la méthode doGet() de la classe HttpServlet dans notre servlet Test. Voici donc le code de notre servlet :
Code : Java - Surcharge de la méthode doGet() dans notre servlet Test
package com.sdzee.servlets;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class Test extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException{
} }
exceptions présents dans la signature de la méthode : HttpServletRequest, HttpServletResponse, ServletException et IOException.
Réessayons alors de contacter notre servlet via notre URL : tout se passe comme prévu, le message d'erreur HTTP disparaît. Cela dit, notre servlet ne fait strictement rien de la requête HTTP reçue : le navigateur nous affiche alors une page… blanche !
Comment le client sait-il que la requête est arrivée à bon port ?
C'est une très bonne remarque. En effet, si votre navigateur vous affiche une simple page blanche, c'est parce qu'il considère la requête comme terminée avec succès : si ce n'était pas le cas, il vous afficherait un des codes et messages d'erreur HTTP… (voir la figure suivante). Si vous utilisez le navigateur Firefox, vous pouvez utiliser l'onglet Réseau de l'outil Firebug pour visualiser qu'effectivement, une réponse HTTP est bien reçue par votre navigateur (si vous utilisez le navigateur Chrome, vous pouvez accéder à un outil similaire en appuyant sur F12 ).
En-têtes de la réponse HTTP avec Firebug On y observe :
un code HTTP 200 OK, qui signifie que la requête s'est effectuée avec succès ; la longueur des données contenues dans la réponse (Content-Length) : 0...
Eh bien encore une fois, c'est le conteneur de servlets qui a fait le boulot sans vous prévenir ! Quand il a généré la paire d'objets requête/réponse, il a initialisé le statut de la réponse avec une valeur par défaut : 200. C'est-à-dire que par défaut, le conteneur de servlets crée un objet réponse qui stipule que tout s'est bien passé. Ensuite, il transmet cet objet à votre servlet, qui est alors libre de le modifier à sa guise. Lorsqu'il reçoit à nouveau l'objet en retour, si le code de statut n'a pas été modifié par la servlet, c'est que tout s'est bien passé. En d'autres termes, le conteneur de servlets adopte une certaine philosophie : pas de nouvelles, bonne nouvelle !
Le serveur retourne donc toujours une réponse au client, peu importe ce que fait notre servlet avec la requête ! Dans notre cas, la servlet n'effectue aucune modification sur l'objet HttpServletResponse, et par conséquent n'y insère aucune donnée et n'y modifie aucun en-tête. D'où la longueur initialisée à zéro dans l'en-tête de la réponse, le code de statut initialisé à 200… et la page blanche en guise de résultat final !