77. Les servlets

Niveau :

Supérieur

A la base, les serveurs web sont seulement capables de renvoyer des fichiers présents sur le serveur en réponse à une requête d'un client. Cependant, pour permettre l'envoi d'une page HTML contenant par exemple une liste d'articles répondant à différents critères, il faut créer dynamiquement cette page HTML. Plusieurs solutions existent pour ces traitements. Les servlets Java sont une de ces solutions.

Mais les servlets peuvent aussi servir à d'autres usages.

Des informations sur les servlets sont disponibles sur la page :
https://www.oracle.com/java/technologies/servlet-technology.html

Ce chapitre contient plusieurs sections :

• La présentation des servlets
• L'API servlet
• Le protocole HTTP
• Les servlets http
• Les informations sur l'environnement d'exécution des servlets
• L'utilisation des cookies
• Le partage d'informations entre plusieurs échanges HTTP
• Packager une application web
• L'utilisation de Log4J dans une servlet

77.1. La présentation des servlets

Une servlet est un programme qui s'exécute côté serveur en tant qu'extension du serveur. Elle reçoit une requête du client, elle effectue des traitements et renvoie le résultat. La liaison entre la servlet et le client peut être directe ou passer par un intermédiaire comme par exemple un serveur http.

Même si pour le moment la principale utilisation des servlets est la génération de pages html dynamiques utilisant le protocole http et donc un serveur web, n'importe quel protocole reposant sur le principe de requête/réponse peut faire usage d'une servlet.

Ecrite en Java, une servlet en retire ses avantages : la portabilité, l'accès à toutes les API de Java dont JDBC pour l'accès aux bases de données, ...

Une servlet peut être invoquée plusieurs fois en même temps pour répondre à plusieurs requêtes simultanées.

Dans une architecture Client/Serveur trois tiers, la servlet se positionne dans le tiers du milieu entre le client léger chargé de l'affichage et la source de données.

Il existe plusieurs versions des spécifications de l'API Servlets :

77.1.1. Le fonctionnement d'une servlet (cas d'utilisation de http)

Un serveur d'applications permet de charger et d'exécuter les servlets dans une JVM. C'est une extension du serveur web. Ce serveur d'applications contient entre autres un moteur de servlets qui se charge de manager les servlets qu'il contient.

Pour exécuter une servlet, il suffit de saisir une URL qui désigne la servlet dans un navigateur.

1. Le serveur reçoit du navigateur la requête http qui a recours à une servlet
2. Si c'est la première sollicitation de la servlet, le serveur l'instancie. Les servlets sont stockées (sous forme de fichiers .class) dans un répertoire particulier du serveur. Ce répertoire dépend du serveur d'applications utilisé. La servlet reste en mémoire jusqu'à l'arrêt du serveur. Certains serveurs d'applications permettent aussi d'instancier des servlets dès le lancement du serveur.
   Au fil des requêtes, la servlet peut être appelée par plusieurs threads lancés par le serveur. Ce principe de fonctionnement évite d'instancier un objet de type servlet à chaque requête et permet de maintenir un ensemble de ressources actives telles qu'une connexion à une base de données.
3. Le serveur crée un objet qui représente la requête http ainsi que l'objet qui contiendra la réponse et les envoie à la servlet
4. La servlet crée dynamiquement la réponse sous forme de page html transmise par un flux dans l'objet contenant la réponse. La création de cette réponse utilise bien sûr la requête du client mais aussi un ensemble de ressources incluses sur le serveur telles que des fichiers ou des bases de données.
5. Le serveur récupère l'objet réponse et envoie la page html au client.

77.1.2. Les outils nécessaires pour développer des servlets

Initialement, pour développer des servlets avec le JDK Standard Edition, il fallait utiliser le Java Server Development Kit (JSDK) qui est une extension du JDK. Pour réaliser les tests, le JSDK fournissait, dans sa version 2.0 un outil nommé servletrunner et depuis sa version 2.1, il fournit un serveur http allégé.

Actuellement, pour exécuter des applications web, il faut utiliser un conteneur web ou un serveur d'applications : il existe de nombreuses versions commerciales telles que IBM Webpshere ou BEA WebLogic mais aussi des versions libres telles que Tomcat du projet GNU Jakarta.

Ce serveur d'applications ou ce conteneur web doit utiliser ou inclure un serveur http dont le plus utilisé est Apache.

Le choix d'un serveur d'applications ou d'un conteneur web doit tenir compte de la version du JSDK qu'il supporte pour être compatible avec celle utilisée pour le développement des servlets. Le choix entre un serveur commercial et un libre doit tenir compte principalement du support technique, des produits annexes fournis et des outils d'installation et de configuration.

Pour simplement développer des servlets, le choix d'un serveur libre se justifie pleinement de part sa gratuité et sa « légèreté ».

77.1.3. Le rôle du conteneur web

Un conteneur web est un moteur de servlets qui prend en charge et gère les servlets : chargement de la servlet, gestion de son cycle de vie, passage des requêtes et des réponses ... Un conteneur web peut être intégré dans un serveur d'applications qui va contenir d'autres conteneurs et éventuellement proposer d'autres services..

Le chargement et l'instanciation d'une servlet se font selon le paramétrage soit au lancement du serveur soit à la première invocation de la servlet. Dès l'instanciation, la servlet est initialisée une seule et unique fois avant de pouvoir répondre aux requêtes. Cette initialisation peut permettre de mettre en place l'accès à des ressources telles qu'une base de données.

77.1.4. Les différences entre les servlets et les CGI

Les programmes ou script CGI (Common Gateway Interface) sont aussi utilisés pour générer des pages HTML dynamiques. Ils représentent la plus ancienne solution pour réaliser cette tâche.

Un CGI peut être écrit dans de nombreux langages.

Il existe plusieurs avantages à utiliser des servlets plutôt que des CGI :

• la portabilité offerte par Java bien que certains langages de script tels que PERL tournent sur plusieurs plates-formes.
  
  
• la servlet reste en mémoire une fois instanciée ce qui permet de garder des ressources systèmes et gagner le temps de l'initialisation. Un CGI est chargé en mémoire à chaque requête, ce qui réduit les performances.
  
  
• les servlets possèdent les avantages de toutes les classes écrites en Java : accès aux API, aux JavaBeans, le garbage collector, ...
  
  

77.2. L'API servlet

Les servlets sont conçues pour agir selon un modèle de requête/réponse. Tous les protocoles utilisant ce modèle peuvent être utilisés : http, ftp, etc ...

L'API servlets est une extension du jdk de base, et en tant que telle elle est regroupée dans des packages préfixés par javax.

L'API servlet regroupe un ensemble de classes dans deux packages :

• javax.servlet : contient les classes pour développer des serlvets génériques indépendantes d'un protocole
  
• javax.servlet.http : contient les classes pour développer des servlets qui reposent sur le protocole http utilisé par les serveurs web.

Le package javax.servlet définit plusieurs interfaces, méthodes et exceptions :

Le package javax.servlet.http définit plusieurs interfaces et méthodes :

77.2.1. L'interface Servlet

Une servlet est une classe Java qui implémente l'interface javax.servlet.Servlet. Cette interface définit 5 méthodes qui permettent au conteneur web de dialoguer avec la servlet : elle encapsule ainsi les méthodes nécessaires à la communication entre le conteneur et la servlet.

Les méthodes init(), service() et destroy() assurent le cycle de vie de la servlet en étant respectivement appelées lors de la création de la servlet, lors de son appel pour le traitement d'une requête et lors de sa destruction.

La méthode init() est appelée par le serveur juste après l'instanciation de la servlet.

La méthode service() ne peut pas être invoquée tant que la méthode init() n'est pas terminée.

La méthode destroy() est appelée juste avant que le serveur ne détruise la servlet : cela permet de libérer des ressources allouées dans la méthode init() telles qu'un fichier ou une connexion à une base de données.

77.2.2. La requête et la réponse

L'interface ServletRequest définit plusieurs méthodes qui permettent d'obtenir des données sur la requête du client :

L'interface ServletResponse définit plusieurs méthodes qui permettent de fournir la réponse faite par la servlet suite à ses traitements :

77.2.3. Un exemple de servlet

Une servlet qui implémente simplement l'interface Servlet doit évidemment redéfinir toutes les méthodes de l'interface.

Il est très utile lorsque que l'on crée une servlet qui implémente directement l'interface Servlet de sauvegarder l'objet ServletConfig fourni par le conteneur en paramètre de la méthode init() car c'est le seul moment où l'on a accès à cet objet.

import java.io.*;
import javax.servlet.*;

public class TestServlet implements Servlet {
  private ServletConfig cfg;

  public void init(ServletConfig config) throws ServletException {
     cfg = config;
  }

  public ServletConfig getServletConfig() {
    return cfg;
  }

  public String getServletInfo() {
    return "Une servlet de test";
  }	

  public void destroy() {
  }

  public void service (ServletRequest req,  ServletResponse res ) 
  throws ServletException, IOException  {
    res.setContentType( "text/html" );
    PrintWriter out = res.getWriter();
    out.println( "<HTML>" );
    out.println( "<HEAD>");
    out.println( "<TITLE>Page generee par une servlet</TITLE>" );
    out.println( "</HEAD>" );
    out.println( "<BODY>" );
    out.println( "<H1>Bonjour</H1>" );
    out.println( "</BODY>" );
    out.println( "</HTML>" );
    out.close();
  }
}

77.3. Le protocole HTTP

Le protocole HTTP est un protocole qui fonctionne sur le modèle client/serveur. Un client qui est une application (souvent un navigateur web) envoie une requête à un serveur (un serveur web). Ce serveur attend en permanence les requêtes sur un port particulier (par défaut le port 80). A la réception de la requête, le serveur lance un thread qui va la traiter pour générer la réponse. Le serveur renvoie la réponse au client une fois les traitements terminés.

Une particularité du protocole HTTP est de maintenir la connexion entre le client et le serveur uniquement durant l'échange de la requête et de la réponse.

Il existe deux versions principales du protocole HTTP : 1.0 et 1.1.

La requête est composée de trois parties :

• la commande
• la section en-tête
• le corps

La première ligne de la requête contient la commande à exécuter par le serveur. La commande est suivie éventuellement d'un argument qui précise la commande (par exemple l'url de la ressource demandée). Enfin la ligne doit contenir la version du protocole HTTP utilisé, précédée de HTTP/.

Exemple :

GET / index.html HTTP/1.0

Avec HTTP 1.1, les commandes suivantes sont définies : GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE et CONNECT. Les trois premières sont les plus utilisées.

Il est possible de fournir sur les lignes suivantes de la partie en-tête des paramètres supplémentaires. Cette partie en-tête est optionnelle. Les informations fournies peuvent permettre au serveur d'obtenir des informations sur le client. Chaque information doit être mise sur une ligne unique. Le format est nom_du_champ:valeur. Les champs sont prédéfinis et sont sensibles à la casse.

Une ligne vide doit précéder le corps de la requête. Le contenu du corps de la requête dépend du type de la commande.

La requête doit obligatoirement être terminée par une ligne vide.

La réponse est elle aussi composée des trois mêmes parties :

• une ligne de statuts
• un en-tête dont le contenu est normalisé
• un corps dont le contenu dépend totalement de la requête

La première ligne de l'en-tête contient un état qui est composé : de la version du protocole HTTP utilisé, du code de statut et d'une description succincte de ce code.

Le code de statut est composé de trois chiffres qui donnent des informations sur le résultat du traitement qui a généré cette réponse. Ce code peut être associé à une catégorie en fonction de sa valeur :

Plusieurs codes sont définis par le protocole HTTP dont les plus importants sont :

• 200 : traitement correct de la requête
• 204 : traitement correct de la requête mais la réponse ne contient aucun contenu (ceci permet au browser de laisser la page courante affichée)
• 404 : la ressource demandée n'est pas trouvée (sûrement le plus célèbre)
• 500 : erreur interne du serveur

L'en-tête contient des informations qui précisent le contenu de la réponse.

Le corps de la réponse est précédé par une ligne vide.

La suite de cette section sera développée dans une version future de ce document

77.4. Les servlets http

L'usage principal des servlets est la création de pages HTML dynamiques. L'API fournit une classe qui encapsule une servlet utilisant le protocole http. Cette classe est la classe HttpServlet.

Cette classe hérite de GenericServlet, donc elle implémente l'interface Servlet, et redéfinit toutes les méthodes nécessaires pour fournir un niveau d'abstraction permettant de développer facilement des servlets avec le protocole http.

Ce type de servlet n'est pas utile seulement pour générer des pages HTML bien que cela soit son principal usage, elle peut aussi réaliser un ensemble de traitements tels que mettre à jour une base de données. En réponse, elle peut générer une page html qui indique le succès ou non de la mise à jour. Une servlets peut aussi par exemple renvoyer une image qu'elle aura dynamiquement générée en fonction de certains paramètres.

Elle définit un ensemble de fonctionnalités très utiles : par exemple, elle contient une méthode service() qui appelle certaines méthodes à redéfinir en fonction du type de requête http (doGet(), doPost(), etc ...).

La requête du client est encapsulée dans un objet qui implémente l'interface HttpServletRequest : cet objet contient les données de la requête et des informations sur le client.

La réponse de la servlet est encapsulée dans un objet qui implémente l'interface HttpServletResponse.

Typiquement pour définir une servlet, il faut définir une classe qui hérite de la classe HttpServlet et redéfinir la méthode doGet() et/ou doPost() selon les besoins.

La méthode service() héritée de HttpServlet appelle l'une ou l'autre de ces méthodes en fonction du type de la requête http :

• une requête GET : c'est une requête qui permet au client de demander une ressource
  
• une requête POST : c'est une requête qui permet au client d'envoyer des informations issues par exemple d'un formulaire
  

Une servlet peut traiter un ou plusieurs types de requêtes grâce à plusieurs autres méthodes :

• doHead() : pour les requêtes http de type HEAD
  
• doPut() : pour les requêtes http de type PUT
  
• doDelete() : pour les requêtes http de type DELETE
  
• doOptions() : pour les requêtes http de type OPTIONS
  
• doTrace() : pour les requêtes http de type TRACE
  

La classe HttpServlet hérite aussi de plusieurs méthodes définies dans l'interface Servlet : init(), destroy() et getServletInfo().

77.4.1. La méthode init()

Si cette méthode doit être redéfinie, il est important d'invoquer la méthode héritée avec un appel à super.init(config), config étant l'objet fourni en paramètre de la méthode. Cette méthode définie dans la classe HttpServlet sauvegarde l'objet de type ServletConfig.

De plus, la classe GenericServlet implémente l'interface ServletConfig. Les méthodes redéfinies pour cette interface utilisent l'objet sauvegardé. Ainsi, la servlet peut utiliser sa propre méthode getInitParameter() ou utiliser la méthode getInitParameter() de l'objet de type ServletConfig. La première solution permet un usage plus facile dans toute la servlet.

Sans l'appel à la méthode héritée lors d'une redéfinition, la méthode getInitParameter() de la servlet lèvera une exception de type NullPointerException.

77.4.2. L'analyse de la requête

La méthode service() est la méthode qui est appelée lors de l'invocation de la servlet.

Par défaut dans la classe HttpServlet, cette méthode contient du code qui réalise une analyse de la requête client contenue dans l'objet HttpServletRequest. Selon le type de requête GET ou POST, elle appelle la méthode doGet() ou doPost(). C'est bien le type de requête qui indique la méthode à utiliser dans la servlet.

Ainsi, la méthode service() n'est pas à redéfinir pour ces requêtes et il suffit de redéfinir les méthodes doGet() et/ou doPost() selon les besoins.

77.4.3. La méthode doGet()

Une requête de type GET est utile avec des liens. Par exemple :

<A HREF="http://localhost:8080/examples/servlet/tomcat1.MyHelloServlet">test de la servlet</A>

Dans une servlet de type HttpServlet, une telle requête est associée à la méthode doGet().

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
}

Le traitement typique de la méthode doGet() est d'analyser les paramètres de la requête, alimenter les données de l'en-tête de la réponse et d'écrire la réponse.

77.4.4. La méthode doPost()

Une requête POST n'est utilisable qu'avec un formulaire HTML.

<FORM ACTION="http://localhost:8080/examples/servlet/tomcat1.TestPostServlet" 
METHOD="POST">
<INPUT NAME="NOM">
<INPUT NAME="PRENOM">
<INPUT TYPE="ENVOYER">
</FORM>

Dans l'exemple ci-dessus, le formulaire comporte deux zones de saisies correspondant à deux paramètres : NOM et PRENOM.

Dans une servlet de type HttpServlet, une telle requête est associée à la méthode doPost().

protected void doPost(HttpServletRequest request, HttpServletResponse response) 
throws IOException {
}

La méthode doPost() doit généralement recueillir les paramètres pour les traiter et générer la réponse. Pour obtenir la valeur associée à chaque paramètre il faut utiliser la méthode getParameter() de l'objet HttpServletRequest. Cette méthode attend en paramètre le nom du paramètre dont on veut la valeur. Ce paramètre est sensible à la casse.

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
   String nom = request.getParameter("NOM");
   String prenom = request.getParameter("PRENOM");
}

77.4.5. La génération de la réponse

La servlet envoie sa réponse au client en utilisant un objet de type HttpServetResponse. HttpServletResponse est une interface : il n'est pas possible d'instancier un tel objet mais le moteur de servlets instancie un objet qui implémente cette interface et le passe en paramètre de la méthode service.

Cette interface possède plusieurs méthodes pour mettre à jour l'en-tête http et la page HTML de retour.

Avant de générer la réponse sous forme de page HTML, il faut indiquer dans l'en-tête du message http, le type MIME du contenu du message. Ce type sera souvent « text/html » qui correspond à une page HTML mais il peut aussi prendre d'autres valeurs en fonction de ce que retourne la servlet (une image par exemple). La méthode à utiliser est setContentType().

Il est aussi possible de préciser la longueur de la réponse avec la méthode setContentLength(). Cette précision est optionnelle mais si elle est utilisée, la longueur doit être exacte pour éviter des problèmes.

Il est préférable de créer une ou plusieurs méthodes recevant en paramètre l'objet HttpServletResponse qui seront dédiées à la génération du code HTML afin de ne pas alourdir les méthodes doXXX().

Il existe plusieurs façons de générer une page HTML : elles utiliseront toutes soit la méthode getOutputStream() ou getWriter() pour obtenir un flux dans lequel la réponse sera envoyée.

• Utilisation d'un StringBuffer et getOutputStream
  
  

  Exemple ( code Java 1.1 ) :

  protected void GenererReponse1(HttpServletResponse reponse) throws IOException { //creation de la reponse StringBuffer sb = new StringBuffer(); sb.append("<HTML>\n"); sb.append("<HEAD>\n"); sb.append("<TITLE>Bonjour</TITLE>\n"); sb.append("</HEAD>\n"); sb.append("<BODY>\n"); sb.append("<H1>Bonjour</H1>\n"); sb.append("</BODY>\n"); sb.append("</HTML>"); // envoi des infos de l'en-tete reponse.setContentType("text/html"); reponse.setContentLength(sb.length()); // envoi de la réponse reponse.getOutputStream().print(sb.toString()); }

  L'avantage de cette méthode est qu'elle permet facilement de déterminer la longueur de la réponse.

  Dans l'exemple, l'ajout des retours chariot '\n' à la fin de chaque ligne n'est pas obligatoire mais facilite la compréhension du code HTML surtout s'il devient plus complexe.

  
  
• Utilisation directe de getOutputStream
  
  

  Exemple :

  import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class TestServlet4 extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); ServletOutputStream out = res.getOutputStream(); out.println("<HTML>\n"); out.println("<HEAD>\n"); out.println("<TITLE>Bonjour</TITLE>\n"); out.println("</HEAD>\n"); out.println("<BODY>\n"); out.println("<H1>Bonjour</H1>\n"); out.println("</BODY>\n"); out.println("</HTML>"); } }

• Utilisation de la méthode getWriter()
  
  

  Exemple ( code Java 1.1 ) :

  protected void GenererReponse2(HttpServletResponse reponse) throws IOException { reponse.setContentType("text/html"); PrintWriter out = reponse.getWriter(); out.println("<HTML>"); out.println("<HEAD>"); out.println("<TITLE>Bonjour</TITLE>"); out.println("</HEAD>"); out.println("<BODY>"); out.println("<H1>Bonjour</H1>"); out.println("</BODY>"); out.println("</HTML>"); }

  Avec cette méthode, il faut préciser le type MIME avant d'écrire la réponse. L'emploi de la méthode println() permet d'ajouter un retour chariot en fin de chaque ligne.

  Si un problème survient lors de la génération de la réponse, la méthode sendError() permet de renvoyer une erreur au client : un code retour est positionné dans l'en-tête http et le message est indiqué dans une simple page HTML.

77.4.6. Un exemple de servlet HTTP très simple

Toute servlet doit au moins importer trois packages : java.io pour la gestion des flux et deux packages de l'API servlet ; javax.servlet.* et javax.servlet.http.

Il faut déclarer une nouvelle classe qui hérite de HttpServlet.

Il faut redéfinir la méthode doGet() pour y insérer le code qui va envoyer dans un flux le code HTML de la page générée.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class MyHelloServlet extends HttpServlet {

   public void doGet(HttpServletRequest request, HttpServletResponse response) 
      throws IOException, ServletException {

      response.setContentType("text/html");

      PrintWriter out = response.getWriter();
      
      out.println("<html>");
      out.println("<head>");
      out.println("<title>Bonjour tout le monde</title>");
      out.println("</head>");
      out.println("<body>");
      out.println("<h1>Bonjour tout le monde</h1>");
      out.println("</body>");
      out.println("</html>");
   }
}

La méthode getWriter() de l'objet HttpServletResponse renvoie un flux de type PrintWriter dans lequel on peut écrire la réponse.

Si aucun traitement particulier n'est associé à une requête de type POST, il est pratique de demander dans la méthode doPost() d'exécuter la méthode doGet(). Dans ce cas, la servlet est capable de renvoyer une réponse pour les deux types de requête.

public void doPost(HttpServletRequest request,HttpServletResponse response) 
throws ServletException,IOException {

   this.doGet(request, response);

}

77.5. Les informations sur l'environnement d'exécution des servlets

Une servlet est exécutée dans un contexte particulier mis en place par le moteur de servlets.

La servlet peut obtenir des informations sur ce contexte.

La servlet peut aussi obtenir des informations à partir de la requête du client.

77.5.1. Les paramètres d'initialisation

Dès que de la servlet est instanciée, le moteur de servlets appelle sa méthode init() en lui donnant en paramètre un objet de type ServletConfig.

ServletConfig est une interface qui possède deux méthodes permettant de connaître les paramètres d'initialisation :

• String getInitParameter(String) : retourne la valeur du paramètre dont le nom est fourni en paramètre
  
  

  Exemple :

  String param; public void init(ServletConfig config) { param = config.getInitParameter("param"); }

  
  
• Enumeration getInitParameterNames() : retourne une énumération des paramètres d'initialisation
  
  

  Exemple ( code Java 1.1 ) :

  public void init(ServletConfig config) throws ServletException { cfg = config; System.out.println("Liste des parametres d'initialisation"); for (Enumeration e=config.getInitParameterNames(); e.hasMoreElements();) { System.out.println(e.nextElement()); } }

La déclaration des paramètres d'initialisation dépend du serveur qui est utilisé.

77.5.2. L'objet ServletContext

La servlet peut obtenir des informations à partir d'un objet ServletContext retourné par la méthode getServletContext() d'un objet ServletConfig.

Il est important de s'assurer que cet objet ServletConfig, obtenu par la méthode init() est soit explicitement sauvegardé soit sauvegardé par l'appel à la méthode init() héritée qui effectue cette sauvegarde.

L'interface ServletContext contient plusieurs méthodes dont les principales sont :

public void init(ServletConfig config) throws ServletException {

   ServletContext sc = config.getServletContext();

   sc.log( "Demarrage servlet TestServlet" );

}

Le format du fichier log est dépendant du serveur utilisé :

Context log path="/examples" :Demarrage servlet TestServlet

77.5.3. Les informations contenues dans la requête

De nombreuses informations en provenance du client peuvent être extraites de l'objet ServletRequest passé en paramètre par le serveur (ou de HttpServletRequest qui hérite de ServletRequest).

Les informations les plus utiles sont les paramètres envoyés dans la requête.

L'interface ServletRequest dispose de nombreuses méthodes pour obtenir ces informations :

package tomcat1;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;

public class InfoServlet extends HttpServlet {

   public void doGet(HttpServletRequest request, HttpServletResponse response) 
      throws IOException,ServletException {
      GenererReponse(request, response);

   }

   protected void GenererReponse(HttpServletRequest request, HttpServletResponse reponse) 
      throws IOException {
 
      reponse.setContentType("text/html");

      PrintWriter out =reponse.getWriter();

      out.println("<html>");
      out.println("<body>");
      out.println("<head>");
      out.println("<title>Informations a disposition de la servlet</title>");
      out.println("</head>");
      out.println("<body>");
      out.println("<p>Type mime de la requête :"
        +request.getContentType()+"</p>");
      out.println("<p>Protocole de la requête :"
        +request.getProtocol()+"</p>");
      out.println("<p>Adresse IP du client :"
        +request.getRemoteAddr()+"</p>");
      out.println("<p>Nom du client : "
        +request.getRemoteHost()+"</p>");
      out.println("<p>Nom du serveur qui a reçu la requête :"
        +request.getServerName()+"</p>");
      out.println("<p>Port du serveur qui a reçu la requête :"
        +request.getServerPort()+"</p>");
      out.println("<p>scheme: "+request.getScheme()+"</p>");
      out.println("<p>liste des paramètres </p>");

      for (Enumeration e =request.getParameterNames() ; e.hasMoreElements() ; ) {
         Object p = e.nextElement();
         out.println("<p>&nbsp;&nbsp;nom : "+p+" valeur :"
            +request.getParameter(""+p)+"</p>");
      }

      out.println("</body>");
      out.println("</html>");
   }
}

Type mime de la requête : null

Protocole de la requête : HTTP/1.0

Adresse IP du client : 127.0.0.1

Nom du client : localhost

Nom du serveur qui a reçu la requête : localhost

Port du serveur qui a reçu la requête : 8080

scheme : http

liste des paramètres

   nom : param2 valeur :valeur2

   nom : param1 valeur :valeur1

77.6. L'utilisation des cookies

Les cookies sont des fichiers contenant des données au format texte. Ils sont créés à l'initiative du serveur et envoyés par le serveur sur le poste client pour leur stockage. Les données contenues dans le cookie sont ensuite renvoyées au serveur à chaque requête.

Les cookies peuvent être utilisés explicitement ou implicitement par exemple lors de l'utilisation d'une session.

Les cookies ne sont pas dangereux car ce sont uniquement des fichiers textes qui ne sont pas exécutés. De plus, les navigateurs posent des limites sur le nombre (en principe 20 cookies pour un même serveur) et la taille des cookies (4ko maximum). Par contre les cookies peuvent contenir des données plus ou moins sensibles. Il est capital de ne stocker dans les cookies que des données qui ne sont pas facilement exploitables par une intervention humaine sur le poste client et en tout cas de ne jamais les utiliser pour stocker des informations sensibles telles qu'un numéro de carte bleue.

77.6.1. La classe Cookie

La classe javax.servlet.http.Cookie encapsule un cookie.

Un cookie est composé d'un nom, d'une valeur et d'attributs.

Pour créer un cookie, il suffit d'instancier un nouvel objet de type Cookie. La classe Cookie ne possède qu'un seul constructeur qui attend deux paramètres de type String : le nom et la valeur associée.

La classe Cookie possède plusieurs getters et setters pour obtenir ou définir des attributs qui sont tous optionnels.

77.6.2. L'enregistrement et la lecture d'un cookie

Pour envoyer un cookie au browser, il suffit d'utiliser la méthode addCookie() de la classe HttpServletResponse.

vCookie monCookie = new Cookie("nom","valeur");
response.addCookie(monCookie);

Pour lire un cookie envoyé par le browser, il faut utiliser la méthode getCookies() de la classe HttpServletRequest. Cette méthode renvoie un tableau d'objets Cookie. Les cookies sont renvoyés dans l'en-tête de la requête http. Pour rechercher un cookie particulier, il faut parcourir le tableau et rechercher le cookie à partir de son nom grâce à la méthode getName() de l'objet Cookie.

Cookie[] cookies = request.getCookies();
String valeur = "";
for(int i=0;i<cookies.length;i++) {
  if(cookies[i].getName().equals("nom")) {
    valeur=cookies[i].getValue();
  }
}

77.7. Le partage d'informations entre plusieurs échanges HTTP

Cette section sera développée dans une version future de ce document

77.8. Packager une application web

Le format war (Web Application Archive) permet de regrouper en un seul fichier tous les éléments d'une application web que ce soit pour le côté serveur (servlets, JSP, classes java, ...) ou pour le côté client (ressources HTML, images, son ... ).

C'est une extension du format jar spécialement dédiée aux applications web qui a été introduite dans les spécifications de la version 2.2 des servlets. C'est un format indépendant de toute plate-forme et exploitable par tous les conteneurs web qui respectent a minima cette version des spécifications.

Le but principal est de simplifier le déploiement d'une application web et d'uniformiser cette action quel que soit le conteneur web utilisé.

77.8.1. La structure d'un fichier .war

Comme les fichiers jar, les fichiers war possèdent une structure particulière qui est incluse dans un fichier compressé de type "zip" possédant comme extension ".war".

Le nom du fichier .war est important car ce nom sera automatiquement associé dans l'url pour l'accès à l'application en concaténant le nom du domaine, un slash et le nom du fichier war. Par exemple, pour un serveur web sur le poste local avec un fichier test.war déployé sur le serveur d'applications, l'url pour accéder à l'application web sera http://localhost/test/.

Le répertoire WEB-INF et le fichier web.xml qu'il contient doivent obligatoirement être présents dans l'archive. Le fichier web.xml est le descripteur de déploiement de l'application web.

Le serveur web peut avoir accès par le serveur d'applications à toutes les ressources contenues dans le fichier .war hormis celles présentes dans le répertoire WEB-INF. Ces dernières ne sont accessibles qu'au serveur d'application.

Le répertoire WEB-INF/classes est automatiquement ajouté par le conteneur au CLASSPATH lors du déploiement de l'application web.

L'archive web peut être créée grâce à l'outil jar fourni avec le JDK ou avec un outil commercial. Avec l'outil jar, il suffit de créer l'arborescence de l'application, de se placer dans le répertoire racine de cette arborescence et d'exécuter la commande :

jar cvf nom_web_app.war .

Toute l'arborescence avec les fichiers qu'elle contient sera incluse dans le fichier nom_web_app.war.

77.8.2. Le fichier web.xml

Le fichier /WEB-INF/web.xml est un fichier au format XML qui est le descripteur de déploiement permettant de configurer : l'application, les servlets, les sessions, les bibliothèques de tags personnalisés, les paramètres de contexte, les types Mimes, les pages par défaut, les ressources externes, la sécurité de l'application et des ressources J2EE.

Le fichier web.xml commence par un prologue et une indication sur la version de la DTD à utiliser. Celle-ci dépend des spécifications de l'API servlet utilisée.

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
  "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

L'élément racine est le tag <web-app>. Cet élément peut avoir plusieurs tags fils dont l'ordre d'utilisation doit respecter celui défini dans la DTD utilisée.

Le tag <icon> permet de préciser une petite et une grande image qui pourront être utilisées par des outils graphiques.

Le tag <display-name> permet de donner un nom pour l'affichage dans les outils.

Le tag <description> permet de fournir un texte de description de l'application web.

Le tag <context-param> permet de fournir un paramètre d'initialisation de l'application. Ce tag peut avoir trois tags fils : <param-name>, <param-value> et <description>. Il doit y en avoir autant que de paramètres d'initialisation. Les valeurs fournies peuvent être retrouvées dans le code de la servlet grâce à la méthode getInitParameter() de l'objet ServletContext.

Le tag <servlet> permet de définir une servlet. Le tag fils <icon> permet de préciser une petite et une grande image pour les outils graphiques. Le tag <servlet-name> permet de donner un nom à la servlet qui sera utilisé pour le mapping avec l'URL par défaut de la servlet. Le tag <display-name> permet de donner un nom d'affichage. Le tag <description> permet de fournir une description de la servlet. Le tag <servlet-class> permet de préciser le nom complètement qualifié de la classe Java dont la servlet sera une instance. Le tag <init-param> permet de préciser un paramètre d'initialisation pour la servlet. Ce tag possède les tags fils <param-name>, <param-value>, <description>. Les valeurs fournies peuvent être retrouvées dans le code de la servlet grâce à la méthode getInitParameter() de la classe ServletConfig. Le tag <load-on-startup> permet de préciser si la servlet doit être instanciée lors de l'initialisation du conteneur. Il est possible de préciser dans le corps de ce tag un numéro de séquence qui permettra d'ordonner la création des servlets.

  <servlet>
    <servlet-name>MaServlet</servlet-name>
    <servlet-class>fr.jmdoudoux.dej.servlet.MaServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
    <init-param>
		  <param-name>param1</param-name>
			<param-value>valeur1</param-value>
    </init-param>

  </servlet>

Le tag <servlet-mapping> permet d'associer la servlet à une URL. Ce tag possède les tags fils <servlet-name> et <servlet-mapping>.

  <servlet-mapping>
    <servlet-name>MaServlet</servlet-name>
	  <url-pattern>/test</url-pattern>
  </servlet-mapping>

Le tag <session-config> permet de configurer les sessions. Le tag fils <session-timeout> permet de préciser la durée maximum d'inactivité de la session avant sa destruction. La valeur fournie dans le corps de ce tag est exprimée en minutes.

  <session-config>
    <session-timeout>15</session-timeout>
	</session-config>

Le tag <mime-mapping> permet d'associer des extensions à un type MIME particulier.

Le tag <welcome-file-list> permet de définir les pages par défaut. Chacun des fichiers est défini grâce au tag fils <welcome-file>

  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file> 
    <welcome-file>index.htm</welcome-file> 
  <welcome-file-list>

Le tag <error-page> permet d'associer une page web à un code d'erreur HTTP particulier ou a une exception java particulière. Le code erreur est précisé avec le tag fils <error-code>. L'exception Java est précisée avec le tag fils <exception-type>. La page web est précisée avec le tag fils <location>.

Le tag <tag-lib> permet de définir une bibliothèque de tags personnalisée. Le tag fils <taglib-uri> permet de préciser l'URI de la bibliothèque. Le tag fils <taglib-location> permet de préciser le chemin de la bibliothèque.

  <taglib>
	  <taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
	  <taglib-location>/WEB-INF/tld/c.tld</taglib-location>
  </taglib>

77.8.3. Le déploiement d'une application web

Le déploiement d'une archive web dans un serveur d'applications est très facile car il suffit simplement de copier le fichier .war dans le répertoire par défaut dédié aux applications web. Par exemple dans Tomcat, c'est le répertoire webapps. Attention cependant, si chaque conteneur qui respecte les spécifications 1.1 des JSP sait utiliser un fichier .war, son exploitation peut différer légèrement.

Par exemple avec Tomcat, il est possible de travailler directement dans le répertoire webapps avec le contenu de l'archive web décompressée. Cette fonctionnalité est particulièrement intéressante lors de la phase de développement de l'application car il n'est alors pas obligatoire de générer l'archive web pour tester chaque modification. Attention, si l'application est redéployée sous la forme d'une archive .war, il faut obligatoirement supprimer le répertoire qui contient l'ancienne version de l'application.

77.9. L'utilisation de Log4J dans une servlet

Log4J est un framework dont le but est de faciliter la mise en oeuvre de fonctionnalités de logging dans une application. Il est notamment possible de l'utiliser dans une application web. Pour plus de détails sur cette API, consultez la section qui lui est consacrée dans le chapitre «Le logging» de cet ouvrage.

Pour utiliser Log4J dans une application web, il est nécessaire d'initialiser Log4J avant utilisation. Le plus simple est d'écrire une servlet qui va réaliser cette initialisation et qui sera lancée automatiquement au chargement de l'application web.

Dans la méthode init() de la servlet, deux paramètres sont récupérés et utilisés pour :

• définir une variable d'environnement qui sera utilisée par Log4J dans son fichier de configuration pour établir le chemin du fichier journal utilisé
• initialiser Log4J en utilisant un fichier de configuration

package fr.jmdoudoux.dej.log4j;

import org.apache.log4j.PropertyConfigurator;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.*;

public class InitServlet extends HttpServlet {
	public void init() {

		String cheminWebApp = getServletContext().getRealPath("/");		
		String cheminLogConfig = cheminWebApp + getInitParameter("log4j-fichier-config");
		String cheminLog = cheminWebApp + getInitParameter("log4j-chemin-log");

		File logPathDir = new File( cheminLog );
		System.setProperty( "log.chemin", cheminLog );
		
		if (cheminLogConfig != null) {
			PropertyConfigurator.configure(cheminLogConfig);
		}	
	}

	public void doGet(HttpServletRequest req, HttpServletResponse res) {
	}
}

Dans le fichier web.xml, il faut configurer les servlets utilisées et notamment la servlet définie pour initialiser Log4J. Celle-ci attend au moins deux paramètres :

• log4j-fichier-config : ce paramètre doit avoir comme valeur le chemin relatif du fichier de configuration de Log4J par rapport à la racine de l'application web
• log4j-chemin-log :  ce paramètre doit avoir comme valeur le chemin du répertoire qui va contenir les fichiers journaux générés par Log4J par rapport à la racine de l'application web

<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <servlet>
    <servlet-name>initservlet</servlet-name>
    <servlet-class>fr.jmdoudoux.dej.log4j.InitServlet</servlet-class>
    <init-param>
      <param-name>log4j-fichier-config</param-name>
      <param-value>WEB-INF/classes/log4j.properties</param-value>
    </init-param>
    <init-param>
      <param-name>log4j-chemin-log</param-name>
      <param-value>WEB-INF/log</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  
  <servlet>
    <servlet-name>TestServlet</servlet-name>
    <servlet-class>fr.jmdoudoux.dej.log4j.TestServlet</servlet-class>
  </servlet>
  
  <servlet-mapping>
    <servlet-name>TestServlet</servlet-name>
    <url-pattern>/test</url-pattern>
  </servlet-mapping>
</web-app>

Il est important de demander le chargement automatique de la servlet en donnant la valeur 1 à son tag <load-on-startup>.

Il faut définir le fichier de configuration nommé par exemple log4j.properties et le placer dans le répertoire WEB-INF/classes de l'application.

# initialisation de la racine du logger avec le niveau INFO
log4j.rootLogger=INFO, A1

# utilisation d'un fichier pour stocker les informations du journal
log4j.appender.A1=org.apache.log4j.FileAppender
log4j.appender.A1.file=${log.chemin}/application.log

# utilisation du layout de base
log4j.appender.A1.layout=org.apache.log4j.SimpleLayout

L'utilisation de Log4J dans une servlet est alors équivalente à celle d'une application standalone.

package fr.jmdoudoux.dej.log4j;

import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.log4j.Logger;

public class TestServlet extends HttpServlet {

  private static final Logger logger = Logger.getLogger(TestServlet.class);

  public void init(ServletConfig config) throws ServletException {
    super.init(config);
    logger.info("initialisation de la servlet TestServlet");
  }
  
  public void doGet(HttpServletRequest req, HttpServletResponse res) {
    StringBuffer sb = new StringBuffer();

    logger.debug("appel doGet de la servlet TestServlet");
    
    sb.append("<HTML>\n");
    sb.append("<HEAD>\n");
    sb.append("<TITLE>Bonjour</TITLE>\n");
    sb.append("</HEAD>\n");
    sb.append("<BODY>\n");
    sb.append("<H1>Bonjour</H1>\n");
    sb.append("</BODY>\n");
    sb.append("</HTML>");

    res.setContentType("text/html");
    res.setContentLength(sb.length());

    try {
      res.getOutputStream().print(sb.toString());
    } catch (IOException e) {
      e.printStackTrace();
    }
  }
}

Lors de l'exécution de l'application web, le journal est stocké dans le fichier /WEB-INF/log/application.log.