5. Définition et chargement des applications web
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.
5.2. Prise en compte des éléments
Context
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.
5.3. Chargement et mise à jour à chaud
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.