Tutoriel sur les Servlets Java

Afin qu'une Servlet puisse accueillir les requêtes venant des clients, nous avons vu dans la section précédente qu'une instance de cette Servlet doit être présente. Le processus de chargement de la Servlet est effectué par le moteur de Servlet. Ce chargement peut être effectué au démarrage du moteur de Servlets ou bien juste au moment où le moteur détermine qu'il a besoin de la Servlet en question.

Tout d'abord, le moteur de Servlets recherche une classe du type de la Servlet à charger à l'endroit où se trouvent les classes des Servlets pour chaque contexte (voir contextes). Si la Servlet n'est pas déjà chargée, le moteur de Servlets charge la Servlet en utilisant un chargeur de classe normal à partir du système de fichier local, ou de toute autre ressource distante (cela dépend des contextes, pour plus de renseignements à propos des contextes, voir contextes). Une fois que la Servlet est chargée, elle est instanciée et un objet du type de la Servlet chargée est donc présent en mémoire. Une Servlet peut être chargée une fois ou plus par le moteur de Servlets, cela dépend du modèle d'exécution choisi : si la Servlet implémente l'interface SingleThreadModel plusieurs instances peuvent être créées en mesure du nombre de requêtes faites par l'utilisateur, si rien n'est précisé par le programmeur (la classe de la servlet n'implémente pas SingleThreadModel) une seule instance de la Servlet peut être présente. Plusieurs instances d'une même Servlet peuvent être créées également si plusieurs Servlets identiques possèdent des paramètres d'initialisation différents.

L'initialisation est la dernière étape du chargement d'une Servlet. Une Servlet doit être initialisée avant de pouvoir répondre aux requêtes provenant du client. En effet, il est possible que certaines variables d'instance (ou toutes) de la classe correspondant à la Servlet à charger requièrent des valeurs de départ, dépendant de paramètres connus seulement au moment où elles sont chargées ou enregistrées lors de leur dernière destruction.Les valeurs de ces paramètres d'initialisation peuvent être précisées par un outil de configuration pour certains moteurs de servlets (comme Java Web Server), par une balise spéciale lorsque l'on utilise SSI (voir section ssi) ou par programme. Le moteur de Servlet effectue cette initialisation en appelant la méthode init(ServletConfig config) de l'interface Servlet. un paramètre de type ServletConfig est passé lors de l'appel de cette méthode. Ainsi, il est possible d'accéder dans le code source de la Servlet aux paramètres d'initialisation employée pour cette dernière. L'objet de type ServletConfig passé en paramètre à cette méthode permet également d'accéder à un objet de type ServletContext (car il implémente l'interface ServletContext) qui décrit l'environnement d'exécution dans lequel tourne la Servlet. Il faut noter que si vous désirez personnaliser l'initialisation de votre Servlet en redéfinissant la méthode init de celle-ci, vous devez impérativement utiliser l'instruction

super.init(config);

en admettant que config soit l'identifiant de l'objet de type ServletConfig passé en paramètre à la méthode init que vous redéfinissez.

Je vous ai décrit le fonctionnement du chargement d'une Servlet dans le cas où tout se déroule comme prévu. Mais qu'en est-il lorsqu'une erreur survient, ou que le chargement de la Servlet n'est pas désiré ? La méthode init peut générer une exception de type ServletException ou UnavailableException. Une fois l'exception générée, le processus de chargement est abandonné et l'instance de la Servlet est immédiatement détruite. La méthode destroy que nous allons découvrir d'ici peu n'est pas appelée dans ce cas. Une fonctionnalité intéressante est fournie par le constructeur de l'exception de type UnavailableException. En effet, il est possible, via un paramètre passé au constructeur de l'exception, d'imposer au moteur de Servlets de respecter un délai avant une nouvelle tentative de chargement de la Servlet dont le chargement vient d'échouer. L'instruction suivante :

throw new UnavailableException("Charge du serveur trop élevée", 120);

permet de respecter un délai de deux minutes avant la prochaine tentative de chargement à cause d'un taux d'occupation de la machine serveur trop élevé.

Le rechargement d'une servlet

Il existe une fonctionnalité mise à disposition des développeurs de servlets lorsqu'ils se trouvent dans une phase de développement soutenue. En effet, plutôt que d'effectuer des manipulations impliquant une interruption de service (le redémarrage du serveur) pour recharger une servlet afin de prendre en compte les modifications apportées au code, c'est le moteur de servlets qui recharge la servlet de façon automatique s'il pense que cela est nécessaire. Ainsi, il suffit de recompiler le code source d'une servlet pour qu'une nouvelle instance de celle-ci remplace l'ancienne instance. On peut également utiliser la commande touch sous Unix en lui passant comme paramètre le fichier de la classe à recharger pour effectuer la même chose (sans le coût d'une recompilation).

Pour déterminer s'il est nécessaire de recharger une classe, le moteur de servlets détermine si le fichier de classe a changé (en déterminant si la date de dernière modification du fichier de classe est bien égale à la date de modification du fichier de classe au moment de son dernier chargement par exemple). S'il a changé, le moteur de servlets arrête le chargeur de classe utilisé pour charger la classe précédente et effectue le chargement de la nouvelle classe avec un nouveau chargeur de classe. Il est nécessaire de passer par cette astuce, car il est impossible de charger deux fois la même classe avec le même ClassLoader.

Cette fonctionnalité peut être fort intéressante pour accélérer la mise à jour du code et ne pas interrompre le service pour cette manœuvre. Cependant, l'utilisation d'un ClassLoader différent de celui utilisé par les autres classes de la même application Web peut poser des problèmes liés au contexte et à la récupération d'éléments partagés, car les références utilisées par les autres classes de l'application peuvent ne plus être valides. Si la notion de contexte est importante pour votre application, je vous conseille de désactiver la possibilité du rechargement de classe à la volée ou de ne pas l'utiliser.

L'exécution consiste, pour une Servlet, à accueillir les connexions initiées par les clients et à traiter leur demande.

En ce qui concerne les Servlets, il est possible de programmer des applications destinées à servir exclusivement les requêtes utilisant le protocole HTTP, ou bien tous types de requêtes. Dans le premier cas, la Servlet doit hériter de la classe HttpServlet, dans l'autre, elle hérite de la classe GenericServlet, toutes deux appartenant au package javax.servlet .

Pour répondre à une requête générique, le moteur de Servlets appelle la méthode service préalablement redéfinie dans le code de votre Servlet. Il est possible d'effectuer tous les traitements que vous désirez à partir de l'appel de cette méthode et de renvoyer la réponse. À cette fin, un objet de type ServletRequest possédant toutes les informations sur la requête et un objet de type ServletResponse permettant de transmettre les données produites au cours des traitements effectués par la Servlet au client sont passés en paramètres à cette méthode service.

Cependant, dans la plupart des cas vous utiliserez une classe héritant de la classe HttpServlet pour programmer vos Servlets.

Lorsqu'une requête est reçue par le moteur de Servlet, celui-ci examine d'abord de quel type de requête (on parle de méthode) il s'agit . Il en existe peu en ce qui concerne le protocole HTTP. Ce sont :

1. GET : afin de demander au serveur de nous transmettre un flux d'information. Cela peut être un fichier statique ou des informations créées dynamiquement (c'est le cas des servlets ou toute autre solution de programmation web côté serveur) ;
2. POST : même utilité que GET, mais les paramètres de la requête sont passés directement au serveur au lieu d'être concaténés à l'URL qui identifie la ressource à laquelle on désire accéder ;
3. HEAD : afin de s'informer sur l'entête renvoyé par le serveur lors d'une requête donnée ;
4. OPTIONS : permet de connaître les services disponibles sur un serveur ;
5. PUT : permet de déposer un fichier dans l'arborescence du système de fichier localisé sur la machine faisant tourner le serveur Web ;
6. DELETE : permet de supprimer un fichier de l'arborescence du système de fichier localisé sur la machine faisant tourner le serveur Web ;
7. TRACE : permet de « pister » une requête afin de voir ce que voit le serveur.

Une fois que la méthode de la requête est identifiée, le moteur de Servlet appelle la méthode adéquate pour la Servlet à laquelle la requête tente d'accéder. Pour cela il appelle d'abord la méthode service de la classe qui se charge alors d'appeler la méthode adéquate. Voici la table de correspondance entre la méthode HTTP et la méthode appelée par le moteur de Servlets :

Deux objets sont passés à ces méthodes lorsqu'elles sont appelées :

1. Un objet de type HttpServletRequest : il possède tous les renseignements sur les paramètres passés à la requête ;
2. Un objet de type HttpServletResponse : il permet d'obtenir un flux de sortie pour communiquer la réponse au client.

Vous pouvez définir plusieurs de ces méthodes dans une servlet. Par exemple dans le cas où une servlet soit appelée par un formulaire qui peut utiliser soit la méthode POST soit la méthode GET pour transmettre sa requête, vous définirez le code de la méthode doGet et de la méthode doPost. Les méthodes présentes dans le tableau constituent l'équivalent de la méthode main pour une application classique ou la méthode start pour une applet. En fait la méthode main est la méthode service, mais elle appelle automatiquement la méthode de votre classe correspondant à la méthode HTTP utilisée par le client qui effectue la requête si vous ne la surchargez pas, ce qui est le cas le plus courant. On peut donc dire que du point de vue du programmeur, la méthode service est négligeable (dans le cas de servlets HTTP).

On remarque également que chacune de ces méthodes peut générer une exception, ce qui suppose que des erreurs peuvent survenir. Que se passe-t-il à ce moment-là ? Tout dépend de l'exception qui est générée. Si c'est une exception du type ServletException, c'est le signe d'une erreur lors du traitement de la requête effectué par la méthode en question (doXXX ou service) et le moteur de servlets doit prendre les mesures appropriées à l'annulation de la requête (terminer le thread créé pour l'occasion, etc.). Si l'erreur produite nécessite une suspension du service fourni par la servlet, c'est une exception du type UnavailableException qu'il faut générer. Si l'on déclare que cette suspension est permanente, grâce au paramètre entier du constructeur de l'exception, le moteur de servlets supprime la servlet des servlets actives, appelle sa méthode destroy et libère l'espace mémoire alloué à l'instance de la servlet. Si le délai passé en paramètre au constructeur de l'exception de type UnavailableException est positif, alors le moteur de servlets peut choisir de ne plus router les requêtes dont la servlet est la cible durant la période passée en argument par le programmeur. Durant la période de l'indisponibilité, le moteur de servlets établit une réponse contenant le code HTTP 503 (service non disponible) pour toute requête dont la cible est la servlet qui a généré l'exception. Il est utile d'adopter ce type de comportement lorsque, par exemple, le SGBD utilisé par la servlet pour enregistrer les données et qui est situé sur une autre machine n'est plus disponible.

Lors de l'apparition d'une erreur, il peut être utile d'informer le serveur web et l'administrateur de celui-ci qu'une erreur s'est produite. Il est également pratique, en vue d'un débogage, de disposer de la trace précise des erreurs qui sont survenues. Les serveurs disposent en général d'un système de fichiers journaux pour cela, et les moteurs de servlets ne font pas exception à la règle. Pour utiliser ces fichiers journaux, il est recommandé d'utiliser la méthode log(String message) ou log(Exception e, String message) de l'interface ServletContext. La première écrit le message dans le journal du serveur, la deuxième ajoute à ce message la trace de la pile (le résultat de e.printStackTrace()).

Pour certaines raisons, le moteur de servlets peut décider s'il doit conserver ou non l'instance (ou les instances) de la Servlet au sein de la machine virtuelle. L'instance d'une Servlet peut être détruite quelques millisecondes après sa création ou après l'arrêt du moteur de Servlets. Rien ne peut contraindre le moteur de Servlets à ne pas détruire l'instance d'une Servlet.

Une fois que le moteur de Servlets a déterminé qu'il n'est plus nécessaire de conserver une instance de la Servlet (par exemple quand le serveur doit libérer de l'espace mémoire, ou lorsque l'exécution du moteur de Servlets est arrêtée), il doit permettre à la Servlet de libérer les ressources qu'elle a acquises au cours de son exécution (que ce soient les buffers utilisés pour l'écriture en sortie, les fichiers lus et écrits ou encore les objets instanciés) et de sauvegarder ce qui doit être persistant. C'est pour cela que le moteur de Servlets appelle la méthode destroy de l'interface Servlet, implémentée par toutes vos Servlets (voir ecrire_premiere_servlet). Avant cela, tous les threads qui ont été créés au sein de la méthode service de la Servlet doivent soit être terminés, soit dépasser un temps défini par le moteur de Servlets.

Une fois la méthode destroy() appelée, le moteur de Servlets ne doit plus router les requêtes provenant des utilisateurs vers la Servlet concernée. Dans le cas où le moteur de servlets pense que l'instance de la servlet puisse être utile à nouveau, il doit créer une nouvelle instance de celle-ci et poursuivre la destruction de la précédente. Une fois que la fin du corps de la méthode destroy() est atteinte, le moteur de servlets doit détruire l'instance de la servlet et rendre l'objet éligible par le ramasse-miettes de la machine virtuelle.

Vous disposez maintenant d'une vue d'ensemble suffisante pour comprendre les différentes étapes que devront emprunter les servlets que vous programmerez. Je vais maintenant aborder un autre concept important qui influe sur le fonctionnement des servlets que vous programmerez au sein du moteur de servlets que vous utilisez : les contextes.

Lorsque vous développez des Servlets, vous développez des applications différentes qui répondent à des exigences différentes et qui ont donc des besoins différents. Par exemple, vous pouvez mettre à disposition des visiteurs de votre site un forum de discussions, une application de configuration du serveur à distance (lorsque vous êtes en congé et que votre patron vous appelle en urgence pour redémarrer le serveur Web) et votre site Web principal. Toutes ces applications sont indépendantes l'une de l'autre, car elles n'utilisent pas les mêmes ressources. Chaque classe correspondant à chaque composant de l'application doit rester visible seulement pour les autres classes de la même application. Par contre, au sein d'une même application, il doit être possible de partager des données facilement.Par exemple, dans l'application de commerce en ligne, une servlet permet aux utilisateurs de s'identifier au moment d'entrer sur le site. Lorsque l'un d'eux effectue un achat, c'est une autre servlet de l'application de commerce en ligne qui sera executée, et elle pourra puiser dans la liste des utilisateurs identifiés pour vérifier que l'acheteur s'est bien identifié. Pour toutes ces raisons, le concept de contexte a été créé.

IV-B-4-a. Définition d'un contexte▲

public void init(ServletConfig config) {

  ServletContext contexte = config.getServletContext();

  /* suite du code */

}

IV-B-4-b. Configuration avec Tomcat▲

jar cfvm application.war META-INF/ MANIFEST.MF -C /usr/local/tomcat/webapps/appli/

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">

<webapp>

  <!-- nom de l'application -->

  <display-name>

  Application de configuration d'un serveur Web à distance

  </display-name>

  <!-- paramètres disponibles dans le contexte de l'application --> 

  <context-param>

    <param-name>Webmaster</param-name>

    <param-value>darktigrou@bigfoot.com</param-value>

  </context-param>

  <!-- définition de la servlet de login -->

  <servlet>

    <servlet-name>login</servlet-name>

    <servlet-class>ServletLogin.class</servlet-class>

    <!-- paramètres d'initialisation de la servlet -->

    <init-param>

      <pram-name>maxlogin</param-name>

      <param-value>1</param-value>

    </init-param>

  </servlet>

 <!-- fin de la définition de la servlet --> 

 <!-- correspondance entre URL et servlets appelées -->

 <servlet-mapping> 

   <!-- toute requête effectuée vers une URL comprenant "/catalog/" 

   est redirigée vers la servlet login -->

   <servlet-name>login</servlet-name> 

    <url-pattern>/login/*</url-pattern> 

  </servlet-mapping> 

  <session-config> 

    <session-timeout>30</session-timeout> 

  </session-config> 

  <mime-mapping> 

    <extension>pdf</extension> 

    <mime-type>application/pdf</mime-type> 

  </mime-mapping> 

  <!-- définition des fichiers utilisés par défaut lors d'une requête concernant 

  une URL ne spécifiant pas de fichier -->

  <welcome-file-list> 

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

    <welcome-file>index.html</welcome-file> 

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

  </welcome-file-list> 

  <!-- définition des pages d'erreur --> 

  <error-page> 

    <!-- pour une erreur de code HTTP 404, c'est le fichier 404.html présent à 

    la racine du contexte qui est transmis au client -->

    <error-code>404</error-code> 

    <location>/404.html</location> 

  </error-page> 

<!-- fin de la configuration du contexte -->

</web-app>

IV-B-4-c. Les différentes choses à savoir à propos des contextes▲