La prise en compte et le chargement des applications web par Tomcat suivent un processus très précis et un peu délicat à comprendre, nous allons l'examiner à présent.
La façon la plus simple de déployer une application dans Tomcat, est de passer par l'outil
de gestion des applications. Il suffit alors de charger le fichier .war
qui
contient l'application, Tomcat s'occupe de la déployer et de la mettre à disposition. Si l'on
n'utilise pas cette méthode (qui n'est pas toujours accessible), alors il faut déployer
ses applications manuellement, ce qui est plus délicat.
La première chose que Tomcat recherche, ce sont les descripteurs de contexte,
(context descriptors), c'est-à-dire des fichiers qui
contiennent un élément Context
. Rappelons que la définition de cet
élément appartient à l'API Servlet, et n'est pas propre à Tomcat.
Où Tomcat va-t-il chercher ces éléments ?
Tomcat commence par rechercher le fichier $CATALINA_BASE/conf/context.xml
. Les
informations que cet élément contient seront partagées par toutes les applications web.
Il recherche ensuite les fichiers
$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default
. Les informations
qu'il contient seront partagées par toutes les applications web de cet hôte virtuel.
Il charge ensuite tous les fichiers
$CATALINA_BASE/conf/[enginename]/[hostname]/[nom_fichier].xml
.
Chacun de ces fichiers peut
avoir n'importe quel nom, dès l'instant qu'il porte l'extension .xml
. Chacun
de ces fichiers est alors associé à une application web, disponible sous le path
nom_fichier
. On peut créer des sous-chemins en utilisant le caractère
#
dans le nom du fichier, à la place du caractère /
. L'application
web par défaut, associée au chemin racine, est associée par convention au fichier
ROOT.xml
.
Si aucun fichier de contexte n'a été trouvé dans
$CATALINA_BASE/conf/[enginename]/[hostname]/[nom_fichier].xml
pour l'application
web donnée, alors Tomcat va chercher le fichier /META-INF/context.xml
. Là
encore deux cas peuvent se présenter. Si l'application est archivée dans un WAR, alors
Tomcat en extrait le fichier context.xml
, et le copie dans
$CATALINA_BASE/conf/[enginename]/[hostname]/[nom_fichier].xml
, où
[nom_fichier]
correspond au nom de l'application web. Ce cas est un peu
dangereux, car le changement de fichier WAR, avec éventuellement la mise à jour du fichier
context.xml
n'est pas vue par Tomcat, qui ne remplace pas ce fichier
[nom_fichier].xml
. Pour ce faire, il faut supprimer l'application web et
la déployer à nouveau en tant que nouvelle application, plutôt que de faire un
redéploiement simple.
Enfin et en dernier recours, Catalina recherche des éléments Context
dans son fichier $CATALINA_BASE/conf/server.xml
.
Dans tous les cas, Tomcat crée une application web associée à chaque contexte trouvé, et
y associe le contenu du répertoire (ou fichier archive)
$CATALINA_BASE/webapp/[nom_webapp]
. Le nom de l'application web est défini suivant
les règles qui viennent d'être décrites. Rappelons que le répertoire dans lequel
se trouvent les applications web est fixé par l'attribut appBase
de l'élément
Host
, et qu'il peut donc être redéfini.
Tomcat est capable de charger des applications web alors qu'il est en fonctionnement, et de mettre à jour celles qu'il gère déjà. On appelle cela le chargement à chaud.
Ce mode est actif pour les hôtes dont l'attribut autoDeploy
a été positionné à
true
. Dans ce cas, si un nouveau répertoire est créé dans
$CATALINA_BASE/webapp
, ou si un fichier .war
y est copié, Tomcat
va tenter de déployer l'application web correspondante.