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 ?

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Java servlet et JSP
Retour au blog Java le soir
Cours & Tutoriaux

Table des matières

Introduction
1. Position de l'API Servlet
2. Présentation
Présentation de Tomcat
1. Un peu d'histoire
2. Organisation des répertoires de Tomcat
2.1. Répertoire bin
2.2. Répertoire conf
2.3. Répertoire lib
2.4. Répertoire log
2.5. Répertoire temp
2.6. Répertoire webapp
2.7. Répertoire work
3. Lancement de Tomcat
3.1. Lancement par défaut
3.2. Accéder à l'administration de Tomcat
3.3. Plusieurs instances de Tomcat
4. Configuration de Tomcat
4.1. Introduction
4.2. Élément Server
4.3. Élément Service
4.4. Élément Connector
4.5. Élément Engine
4.6. Élément Host
4.7. Élément Context
4.8. Élément GlobalNamingResources
4.9. Élément Realm
4.10. Élément Valve
5. Définition et chargement des applications web
5.1. Introduction
5.2. Prise en compte des éléments Context
5.3. Chargement et mise à jour à chaud
6. Utilisation de Tomcat avec Apache
API Servlet
1. Introduction
2. Une première servlet
2.1. Le code
2.2. Création de l'application web
2.3. Déploiement dans Tomcat
3. Concepts, cycle de vie
3.1. Requête
3.2. Réponse
3.3. Session
3.4. Application web
3.5. Contexte d'exécution
3.6. Cycle de vie
3.7. Filtre
4. Présentation générale de l'API
4.1. Introduction
4.2. Interfaces disponibles
5. Notion de servlet
5.1. Interfaces servlet
5.2. Cycle de vie d'une servlet
5.3. Paramètres d'initialisation d'une servlet
6. Notion de requête
6.1. Accès aux paramètres d'une requête
6.2. Accès aux éléments de l'en-tête HTTP
6.3. Accès aux éléments de l'URL
6.4. Accès aux paramètres du client
6.5. Accès aux informations de sécurité
6.6. Accès à la session, au contexte et aux informations d'initialisation
7. Notion de réponse
7.1. Contrôle du buffer de sortie
7.2. Contrôle de la réponse HTTP
8. Notion de session HTTP
9. Redirection ou inclusion d'une ressource
10. Listeners
10.1. Introduction
10.2. Événements de l'API Servlet
10.3. Ajout ou retrait d'un attribut
10.4. Création et destruction d'un contexte
10.5. Notification d'un objet attaché à un contexte
10.6. Déclaration d'un listener dans une application web
11. Connexion à une base
11.1. Introduction
11.2. Connexion manuelle
11.3. Connexion par utilisation de source de données
Filtrage
1. Filtrage de servlets
2. Mise en place d'un filtre
2.1. Écriture d'un filtre
2.2. Déclaration du filtrage
3. Filtrage d'une requête
4. Filtrage d'une réponse
4.1. Fonctionnement de ce filtrage
Java Server Pages
1. Introduction
2. Un premier exemple
2.1. Une première JSP statique
2.2. Une première JSP dynamique
2.3. Fonctionnement interne des JSP
3. JSP scriplet
3.1. Les expressions
3.2. Les déclarations
3.3. Variables prédéfinies
3.4. Scriplet de directives
4. Utilisation de beans
4.1. Introduction
4.2. Déclaration d'un bean existant
4.3. Création d'un nouveau bean
4.4. Utilisation des propriétés d'un bean
5. Inclure un contenu externe dans une JSP
5.1. Introduction
5.2. Inclusion au lancement de l'application
5.3. Inclusion au traitement de la requête
6. Utilisation de bibliothèques de tags
6.1. Introduction
6.2. Bibliothèque core
7. Internationalisation
7.1. Notion de bundle
7.2. Internationalisation de pages JSP
Projet exemple
1. Présentation du projet