Annonces
|
|
|
|
 |
||
 |
 |
 |
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://www.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.
Tomcat est un servlet - c'est à dire un programme Java tournant sur un serveur - qui gère d'autres servlets et des pages serveur Java (JSP ou Java Server Pages) permettant de générer des pages web dynamiques. 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 ", dont la consultation est fortement recommandée pour un usage avancé de Tomcat.
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 entraîne le fait 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.
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). Ainsi, il est par exemple possible, en modifiant ces scripts, de modifier la taille de l'espace mémoire alloué à la machine virtuelle Java dans laquelle est exécuté Tomcat.
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.
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 :
C'est le principal fichier de configuration de Tomcat, il permet de paramétrer la majeure partie de son comportement.
La partie la plus 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 le fichier exemple, il suffit donc d'écrire :
<Context path="/examples"
docBase="webapps/examples"
crossContext="false"
debug="0"
reloadable="true"
trusted="false">
</Context>
Ce fichier permet également d'affiner la configuration de Tomcat. Il est ainsi possible, par exemple, de paramétrer le nombre de requêtes simultanées gérées par Tomcat. Ce nombre est par défaut à 30, ce qui est très peu pour un serveur destiné à recevoir des connexions multiples. Pour modifier ce nombre, il suffit d'ajouter le paramètre " max_threads " dans le fichier parmi les paramètres du Connecteur suivant :
<Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/> <Parameter name="port" value="8080"/> <Parameter name="max_threads" value="1000"/> </Connector>
Ces quelques lignes permettent dont de modifier le nombre de processus supportés par Tomcat (attention tout de même à le dimensionner convenablement en fonction du serveur ) mais aussi de modifier le port par défaut : le numéro de port 8080 peut ainsi être modifié en 80, valeur plus appropriée aux connexions HTTP.
Le répertoire " webapps " contient plusieurs sous répertoires qui sont tous organisés de façon analogue. Le premier est 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 : " localhost: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 " localhost:8080/exemple/servlet/Hello " et non pas " localhost:8080/exemple/WEB-INF/classes/Hello.class ". Tomcat reconnaît donc le répertoire virtuel " servlet ".
Le répertoire virtuel servlet peut avantageusement être remplacé en configurant le fichier " web.xml " qui se trouve à la racine du répertoire WEB-INF (s'il n'y est pas, il suffit d'en ajouter un qui soit vierge).
En ajoutant quelques lignes au fichier, il est possible de définir complètement l'adresse des différents Servlet et pages JSP.
Exemple de fichier web.xml :
< !-- en tête (obligatoire pour définir le type du fichier) --> <?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"> <web-app> <!-- Balise début de fichier de configuration --> <servlet> <servlet-name> nom_servlet <!-- Association d’un nom au servlet --> </servlet-name> <servlet-class> classe_servlet <!-- Association de la classe correspondante --> </servlet-class> </servlet> <servlet-mapping> <servlet-name> nom_servlet <!—Choix du servlet visé par le mapping --> </servlet-name> <url-pattern> motif <!—Choix de la forme de l’adresse sur l’URL --> </url-pattern> </servlet-mapping> </web-app><!-- Balise fin de fichier de configuration -->
Ainsi, en remplaçant dans ce fichier générique " nom_servlet " par " premier_servlet ", " classe_servlet " par Hello et enfin " motif " par " / ", il est possible d'accéder au servlet Hello grâce à deux adresses :
<http://localhost:8080/exemple/servlet/Hello>
<http://localhost:8080/exemple/Hello>
Si " motif " est remplacé par " /exemple1 ", il sera possible d'accéder au servlet grâce à ces deux adresses :
<http://localhost:8080/exemple/servlet/Hello>
<http://localhost:8080/exemple/exemple1>
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>
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.
Sun Microsystem a développé un ensemble de classes pour la mise en œuvre de programmes Java destinés à être utilisés sur un serveur. Ces classes ne peuvent fonctionner qu'à l'aide d'un gestionnaire de Servlets. Les gestionnaires ne sont pas développés par Sun. Ce dernier a donc rédigé des spécifications afin d'assurer l'inter compatibilité des différents gestionnaires existants. L'évolution des différentes versions de Tomcat tendent donc à répondre à la majeure partie de ces spécifications. C'est à ce titre qu'il est recommandé, quasi officiellement, par Sun pour implémenter des Servlets et des JSP : Java Server Pages.
Les servlets 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 le 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.
Les JSP sont des fichiers HTML spéciaux qui ont pour extension " .jsp " et qui intègrent des commandes Java. Ce ne sont cependant pas des pages Scripts comme en PHP. En effet, lors d'une requête sur une page JSP, celle ci est compilée afin d'être convertie en servlet. Si la phase de compilation peut demander plus de temps qu'une simple interprétation de Scripts, celle ci n'a lieu qu'une seule fois, pour peu que la page n'ait pas été modifiée entre temps. Cela présente donc un avantage certain par rapport aux langages Scripts puisqu'une fois compilé, le programme s'exécute plus rapidement que s'il devait être interprété.
Pour compiler et exécuter 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 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 programmes serveur et des pages web dynamiques.
|
||
|
|
|