2. Le gestionnaire de servlets Tomcat

a. Introduction

Le but de cette partie est de présenter l'outil Tomcat, son utilisation et ses spécificités. Elle n'a pas vocation à être exhaustive - pour cela, le lecteur se référera à la documentation en ligne du projet Jakarta : http://jakarta.apache.org - mais elle peut servir à l'utilisateur débutant pour découvrir les possibilités de cet outil. Les problèmes d'installation, de configuration et d'utilisation seront abordés après une présentation plus précise de Tomcat.

b. Présentation de Tomcat

Tomcat est un servlet - c'est à dire un programme tournant sur un serveur - qui gère d'autre servlets permettant de générer des pages web dynamiques. Il gère en particulier des servlets Java et des pages serveur java (JSP ou Java serveur pages). Il peut être utilisé seul ou couplé avec un serveur (dont la liste est spécifiée dans la documentation). Tomcat répond aux spécifications de Sun concernant les servlets et leurs gestionnaires. Il supporte à ce titre l'ensemble des classes définies par Sun dans le document " Java API Servlet Spécifications ". Tomcat est totalement gratuit et généralement utilisé en couplage avec un serveur Apache. Ecrit en Java, il nécessite, pour pouvoir fonctionner, la présence d'une machine virtuelle Java, et plus précisément du SDK - Sun Developpement Kit - complet. Ceci implique que Tomcat est totalement portable et peut être mis en oeuvre sur des systèmes radicalement différents, tels que Linux ou Windows. Il faut cependant noter que, sous Windows, l'utilisation de Tomcat est moins sécurisée et plus difficile à configurer sur des systèmes Windows 95/98 puisque Tomcat ne peut y modifier dynamiquement les variables d'environnement.

c. Installation

La procédure d'installation est relativement simple :

•   Il faut installer le SDK (version 1.3.0 ou 1.3.1) et renseigner les variables d'environnement " classpath ".
•   Il faut ensuite décompresser l'archive Jakarta-Tomcat correspondant à la version de Tomcat à installer (téléchargée au préalable à l'adresse http://jakarta.apache.org/tomcat) puis la décomprésser. Il faut ensuite ajouter deux variables d'environnement : JAVA_HOME et TOMCAT_HOME, qui correspondent aux endroits où se situent les archives du SDK et de Tomcat. (on peut également plus simplement ajouter la variable locale JAVA_HOME au début des scripts "startup" et "shutdown" cités ci dessous : sous windows, il faut donc ajouter : set JAVA_HOME=<chemin du répertoire où est installé le SDK> )
•   Il suffit ensuite de lancer le script " startup " (du répertoire " bin " de TOMCAT_HOME) pour démarrer l'exécution de Tomcat. (Le script a pour extension " .sh " sous Linux et " .bat " sous Windows. Sous Linux, il faut veiller à rendre le script exécutable.).
•   Pour arrêter Tomcat, il suffit d'exécuter le script " shutdown ".

Il faut noter que les scripts fournis dans le répertoire " bin " ne sont qu'une manière pratique de démarrer puis d'arrêter Tomcat et que l'utilisateur peut les modifier à sa guise (et à ses risques et périls).

d. Arborescence des répertoires

Le répertoire contenant les archives Tomcat (TOMCAT_HOME) est décomposé en plusieurs sous répertoires qui ont chacun une grande importance. Voici le détail de leur contenu et de leur utilisation.

Le premier répertoire, appelé " bin " contient les différents scripts et outils utiles au démarrage, à la configuration et à l'arrêt de Tomcat.

Le second répertoire, appelé " conf " contient les différents fichiers de configuration de Tomcat. Les plus importants sont les fichiers " .xml ", c'est eux qui vont offrir la possibilité à l'utilisateur de paramétrer Tomcat en fonction de ses besoins. (Le paramétrage de Tomcat sera traité dans les parties qui vont suivre).

Le répertoire " doc " n'est pas nécessaire à l'exécution de Tomcat, il contient simplement le manuel de référence du logiciel.

Le répertoire " lib " contient les différentes librairies Java (" .jar "). Il s'agit des packages JSP et Servlet développés par Sun. Ces classes sont nécessaires à la compilation des programmes, notamment lors des phases de développement.

Le répertoire " logs " est le répertoire dans lequel Tomcat stocke les fichiers " .log ", qui servent notamment à donner des comptes rendus d'activité de la part du programme.

Le répertoire " src " contient les sources principales et publiques de Tomcat.

Le répertoire " webapps " est le répertoire qui contient les pages html, jsp ou les servlets java. Bref, toutes les ressources qui seront sollicitées par l'internaute. Ce point sera plus largement développé au moment d'aborder les fichiers de configuration, mais il faut savoir que ce sont les fichiers contenus dans le répertoire ROOT qui seront considérés comme étant à la racine du serveur (vu coté client).

Le répertoire " work " est automatiquement généré par Tomcat, c'est dans ce dernier que Tomcat place les fichiers temporaires nécessaires à son exécution. (Il est d'ailleurs déconseillé de supprimer les fichiers de ce répertoire au cours de son exécution).

Enfin, l'ajout d'un répertoire " classes " permet d'accoler de nouveaux chemins à la variable d'environnement " classpath ". Toutes les classes contenues dans ce répertoire seront ajoutées dynamiquement au " classpath " de Tomcat.

e. Configuration

La configuration de Tomcat s'effectue à l'aide des fichiers " .xml " se trouvant dans le répertoire " conf ". Le langage XML est, comme le HTML, un langage script basé sur des balises. C'est donc l'état de ces différentes balises qui va définir le comportement de Tomcat. Voici les principales caractéristiques de configuration pour chacun des fichiers :

i. Le fichier server.xml :

La partie intéressante, le gestionnaire de contexte, se trouve vers la fin du fichier. Il s'agit des balises " Context " qui permettent d'ajouter des répertoires dans l'arborescence du répertoire " webapps " (répertoire contenant les ressources du client).

Pour ajouter un nouveau répertoire à l'arborescence, il faut définir un nouveau contexte. Pour cela, une balise " Context " est ajoutée ; elle contient les attributs suivants:

•   " Path " est le chemin utilisé dans les URL. Par exemple, pour un " path " du type " /exemple ", toutes les URL commençant par le répertoire " /exemple " iront chercher les ressources dans ce répertoire.
•   " docBase " est le chemin du répertoire dans lequel se trouvent les ressources correspondant au contexte qui est définit. Ce chemin peut être absolu ou relatif au répertoire où Tomcat est installé.
•   " debug " : par défaut à 0, il peut aller jusqu'à 9. Cela correspond à la quantité de détails des rapports envoyés par Tomcat dans les fichiers " .log " ; cela étant surtout utile dans les phases de développement
•   " reloadable " prend la valeur " true " ou " false " si l'utilisateur souhaite que Tomcat tienne compte ou non des changements effectués au cours de son exécution dans les répertoires contenant les classes Java ou les JSP. Si " reloadable " est à " false ", ces changements seront ignorés.
•   " trusted " est mis à " true " si une des applications doit avoir recours à l'une des classes internes de Tomcat. Normalement, cette option n'est utilisée que par des applications dédiées aux administrateurs.

Pour ajouter le fichier exemple, il suffit donc d'écrire :

<Context path="/examples"
                 docBase="webapps/examples" 
                 crossContext="false"
                 debug="0"
                 reloadable="true"
                 trusted="false">
</Context>

ii. Arborescence des sous répertoires du répertoire " webapps "

Le répertoire " webapps " contient plusieurs sous répertoires qui sont tous organisés de façon analogue. Il y a tout d'abord le répertoire ROOT. C'est dans celui-ci que Tomcat va chercher les ressources par défaut (par exemple quand l'utilisateur tape l'URL " localhost:8080 ").

L'utilisateur accède, à partir d'un navigateur, aux ressources des autres répertoires en tapant l'URL suivante : " localhaost:8080/autre_repertoire " (il faut tout de même que ce répertoire soit répertorié dans le " context path " : Cf. e.i ).

Chaque sous-répertoire du répertoire " webapps " contient deux autres répertoires : " META-INF " et " WEB-INF ". Le dossier " META-INF " contient de simples fichiers d'informations, tandis que le répertoire " WEB-INF " joue un rôle beaucoup plus important.

Il contient un fichier " web.xml " qui permet d'affiner la configuration de Tomcat pour certaines ressources (Cf. Servlet API Spécifications ou la documentation de Tomcat) ainsi que deux autres répertoires : l'un nommé " jsp ", contenant les pages serveur Java, et l'autre appelé " classes " qui contient les classes des servlets Java.

Pour exécuter un servlet " Hello.class " contenu dans le répertoire " WEB-INF " du répertoire " exemple ", l'utilisateur tape l'URL " http://localhost:8080/exemple/servlet/Hello " et non pas " http://localhost:8080/exemple/WEB-INF/classes/Hello.class ". Tomcat reconnaît donc le répertoire virtuel " servlet ". Il vaut mieux d'ailleurs éviter de nommer un répertoire " servlet " qui risque de faire doublon avec le répertoire " servlet " virtuel de Tomcat.

iii. Le fichier jni_server.xml

Ce fichier, pour ajouter ou supprimer l'accès à un répertoire, doit être modifié en ajoutant les lignes suivantes - si l'utilisateur souhaite ajouter un répertoire " exemple ". Pour plus de détails, se référer à la documentation ou examiner le fichier générique fourni, qui est largement commenté.

<Context path="/examples" 
                 docBase="webapps/examples" 
                 debug="0" 
                 reloadable="true"> 
</Context>

iv. Les autres fichiers de configuration

Il existe deux autres fichiers de configuration : les fichiers " build.xml " et " web.xml ". Leur utilisation est détaillée dans les spécifications de Sun.

Le fichier " web.xml " permet, entre autres, de donner des informations sur le type de ressources chargées au démarrage ( en bas du fichier fournis, les balises " welcome-files " ont pour valeur " index.html ", " index.htm " et " index.jsp "). Les autres balises du fichier spécifient les différents formats pris en charge par le serveur.

f. Développement de servlet avec Tomcat

Les servlets gérés par Tomcat possèdent deux méthodes : La méthode " doGet " et la méthode " doPost " qui prennent toutes deux en argument des objets de type HttpServletRequest et HttpServletResponse. Ces deux méthodes seront exécutées lors d'une requête sur la servlet. Si la requête est de type " Get ", c'est la méthode " doGet " qui sera exécutée par Tomcat, et inversement, si la requête est du type " Post ", c'est la méthode " doPost " qui sera exécutée.

Pour compiler les applications Java, il ne faut pas oublier d'ajouter à la variable d'environnement " classpath " le chemin des archives " .jar " nécessaires et se trouvant à l'adresse <TOMCAT-HOME/lib> : en particulier l'archive " servlet.jar ", presque toujours indispensable. Pour savoir quelles archives importer, se référer aux paramètres " import " du code source. L'exécution du code compilé peut se faire directement à l'aide de Tomcat (en créant éventuellement une page " .html " associée qui permettra d'exécuter une requête sur la servlet).

g. Conclusion

Tomcat est un outil extrêmement puissant et pratique pour mettre en œuvre un serveur gérant de nombreux servlets Java. Les utilisateurs réguliers regretteront simplement le manque de transparence des différents fichiers de configuration : il aurait ainsi été intéressant de créer un outil pour les gérer. Même si Tomcat, est d'après certains, moins performant que d'autres outils du même type, il faut noter sa très grande portabilité (puisque totalement écrit en java), sa compatibilité avec des serveurs comme Apache et surtout sa gratuité. C'est enfin un outil qui permet, à tout programmeur connaissant bien le langage Java, de développer rapidement et efficacement des servlets.