Qu'est-ce qu'un descripteur de déploiement ?

Le descripteur de déploiement d'une application web est un fichier nommé web.xml et situé dans le répertoire WEB-INF du document root (répertoire racine) de l'application web. Il contient les caractéristiques et paramètres de l'application. Cela inclut la description des servlets utilisées, ou les différents paramètres d'initialisation. Nous allons à présent étudier l'architecture de ce fichier.

Architecture simplifiée du fichier web.xml

Dans le fichier web.xml, tout se passe entre les balises web-app. Voyons à présent les différentes balises que l'on peut, ou que l'on doit, insérer entre ces deux-là.

Description de l'application

Deux balises relèvent de la description de l'application. La première, display-name permet de donner un nom à l'application. Il s'agit de description, pour s'y retrouver dans les fichiers. Cela n'a pas d'incidence sur le fonctionnement de la webapp. La balise description permet de fournir une description plus détaillée. De même, elle est inopérante techniquement parlant.

Inventaire des servlets

Il convient ensuite de déclarer les servlets que l'application utilise. C'est-à-dire les servlets potentiellement accessibles par les clients, au travers d'une URL.

Les balises <servlet> et </servlet> doivent encadrer la déclaration d'une servlet. On doit affecter un nom à chaque servlet déclarée, dans une balise servlet-name. Ce nom n'est pas nécessairement le nom de la classe de la servlet. Il s'agit d'un identifiant interne au fichier web.xml, réutilisé par la suite. Une fois de plus, la balise description permet de fournir une information plus poussée sur la servlet, si on le souhaite. Cela n'a pas d'utilité technique, cette description n'est visible qu'ici. Enfin, il est bien sûr indispensable de définir la classe de la servlet, dans la balise servlet-class. Rappelons que cette classe doit se trouver dans le répertoire WEB-INF/classes de l'application, en respectant les packages. Dans notre cas, la classe devra être WEB-INF/classes/org/test/servlet/PremiereServlet.class.

Il est possible de spécifier des paramètres d'initialisation pour une servlet. Il s'agit de paramètres chargés en même temps que la servlet, et qu'elle peut récupérer. Dans notre exemple, on peut imaginer fournir le nom d'une classe dont la servlet aura besoin. Ce genre de paramètre se déclare au sein de balises init-param. La balise param-name permet alors de définir le nom du paramètre, sa valeur étant spécifiée dans la balise param-value. L'application peut récupérer un tel paramètre grâce à la méthode getServletConfig().getInitParameter("random"), le paramètre à fournir à la méthode étant un param-name de ce fichier, pour en récupérer la param-value.

La balise load-on-startup demande que la servlet soit chargée dès le démarrage du serveur (et non lors de sa première sollicitation). Le nombre entier situé à l'intérieur de ces balises représente l'ordre de chargement. S'il y avait plusieurs servlets dans ce fichier, on pourrait définir la position 2 de chargement pour une autre...

Mapping des servlets

Le mapping d'une servlet sert à indiquer au serveur quelle servlet charger pour tel requête du client (telle URL demandée). Rappelons que les URL des servlets sont relatives à l'URL du Context (la webapp) auquel elles appartiennent.

Effectuer un mapping est très simple, et se déroule au sein d'une balise servlet-mapping. Il faut spécifier le nom de la servlet à mapper (balise servlet-name). Ce nom doit correspondre à un nom de servlet défini dans la déclaration des servlets (voir paragraphe précédent). Puis, dans la balise url-pattern, définir l'URL par laquelle cette servlet est accessible. Il s'agit bien d'une pattern, car il est possible d'utiliser des caractères spéciaux. L'instruction <url-pattern>/test/*</url-pattern> est ainsi tout à fait valable, et appelera la servlet mappée dès que l'URL contiendra la séquence "/test/" (n'importe quelle URL commençant par "/test/").

Dans notre exemple, si le path du Context de l'application web est "/appli", l'URL "http://localhost:port/appli/uneservlet" appelera, en fonction du mapping, la servlet nommée dans le fichier maservlet, c'est-à-dire la classe org.test.servlet.PremiereServlet.

Paramètres de contexte

Il est également possible de définir des paramètres de contexte pour une application web. A la différence des paramètres d'initialisation de servlets, ceux-ci seront accessibles par toutes les servlets de l'application web dont ce fichier est le descripteur de déploiement.

Rien de révolutionnaire dans la déclaration d'un tel paramètre, entre les balises context-param. Les balises param-name et param-value permettent respectivement de définir le nom du paramètre et sa valeur. Quant à la balise description, elle autorise comme d'habitude l'apposition d'une petite description, non opérante techniquement.

Une servlet peut récupérer un tel paramètre grâce à la méthode getServletContext().getInitParameter("applicationName"), le paramètre à fournir à la méthode étant un param-name de ce fichier, pour en récupérer la param-value.

Attributs de session

La balise session-timeout permet de définir la durée, en minutes, pendant laquelle la session d'un utilisateur (objet Java HttpSession géré par le serveur) reste active.

Fichiers index

Un descripteur de déploiement permet également de spécifier les fichiers d'accueil de l'application web. Dans notre exemple, si le path du Context de l'application web est "/appli", l'URL "http://localhost:port/appli" appelle la page d'accueil. Le serveur cherchera donc la page index.html dans le document root de l'application. Si elle n'existe pas (mieux vaut alors ne pas la fournir dans cette liste !), le fichier index.jsp sera recherché. Notons que, dans Tomcat 5 (spécification 2.4 des servlets), l'on peut définir une servlet comme fichier d'accueil, en insérant dans la liste son servlet-name.

Mapping de types MIME

Lorsque le serveur recevra une requête pour une ressource statique (fichier HTML, image, fichier multimédia...), il enverra la ressource s'il la trouve. Dans la réponse HTTP, il devra paramétrer l'en-tête Content-Type (type de contenu). Pour ce faire, il se basera sur ces types MIME mappés, en fonction de l'extension du fichier à retourner. Donc, si le fichier alaplage.avi lui est demandé, il définira le Content-Type comme video/x-msvideo. Ceci est présenté ici à titre d'information. Notons bien que les mapping de types MIME sont prévus dans le fichier web.xml général de Tomcat (TOMCAT_HOME/conf/web.xml). On peut donc en rajouter directement dans ce fichier. Néanmoins, il est utile de savoir que l'on peut en définir dans tous les descripteurs de déploiement, et limiter ainsi leur portée à l'application concernée.

Et ainsi de suite...

Un descripteur de déploiement peut contenir beaucoup d'autres informations : sécurité, pages d'erreurs, références d'EJB, ou encore filtres sont des éléments possibles à configurer ici. Mais ils sortent largement du cadre de ce site pour l'instant. Ces informations mériteront d'être ajoutées plus tard.