3. Lancement de Tomcat

3.1. Lancement par défaut

La distribution par défaut de Tomcat permet de le lancer avec une adaptation minimale de la configuration. Pour que le lancement se déroule bien, il faut vérifier que la variable JAVA_HOME soit bien positionnée sur une installation du JDK ou du JRE qui correspondent à la version de Java dont Tomcat a besoin (1.6 pour Tomcat 6.0.*). Ensuite, il suffit de se placer dans le répertoire bin, et de taper la commande :
> startup
Une fenêtre s'ouvre alors, qui détaille le déroulement des opérations de lancement, et très rapidement finit par nous afficher le message suivant :
INFO: Server startup in 351 ms
Il suffit alors d'ouvrir un navigateur, et de le faire pointer vers l'URL :8080/, on obtient la page d'accueil suivante.
Page d'accueil de Tomcat

Figure 2. Page d'accueil de Tomcat


Cette page d'accueil permet d'accéder à l'intégralité de la documentation de Tomcat, en local (cartouche Documentation ), aux ressources en ligne sur le site de l'ASF, et à des exemples de servlet ou de JSP. Le cartouche Administration n'est pas encore accessible : il faut pour cela modifier certains droits d'accès, ce que nous allons faire.

3.2. Accéder à l'administration de Tomcat

Administrer un serveur Tomcat signifie entre autres pouvoir allumer ou éteindre certaines applications web. Autoriser n'importe quel utilisateur de faire ce genre de choses serait assez dangereux ! C'est la raison pour laquelle cette application d'administration est inaccessible dans la distribution de Tomcat. C'est d'ailleurs ce que nous dit la page d'accueil : l'accès à cette application est réservé aux utilisateurs possédant le rôle manager . Dans la configuration par défaut, les rôles et les utilisateurs sont définis dans le fichier conf/tomcat-users.xml. Tomcat supporte bien sûr d'autres moyens de définir ce point, il sait entre autres accéder à des bases de données pour aller chercher ce genre d'informations. Le fichier tomcat-users.xml est vide, et contient des exemples de déclaration de rôles et d'utilisateurs mis en commentaires. Il nous faut créer un rôle manager , et un utilisateur qui possède ce rôle.

Exemple 1. Création d'un rôle manager dans tomcat-users.xml

 <?xml version='1.0' encoding='utf-8'?>

 <tomcat-users>
	 <!-- création du rôle manager -->
	 <role  rolename="manager"/>
	
	 <!-- création d'un utlisateur possédant ce rôle -->
	 <user  username="tomcat"  password="tomcat"  roles="manager"/>
 </tomcat-users>

Il faut redémarrer Tomcat pour que ce fichier soit pris en compte. L'arrêt de Tomcat se fait en tapant la commande :
> shutdown
Un fois redémarré Tomcat, on peut cliquer sur le lien Status du cartouche d'administration. On obtient alors une page qui ressemble à la page suivante.
Page de statut de Tomcat

Figure 3. Page de statut de Tomcat


On peut également obtenir la liste des applications web actives.
Liste des applications web chargées

Figure 4. Liste des applications web chargées


3.3. Plusieurs instances de Tomcat

Pour un certain nombre de raisons (bonnes ou mauvaises...), on peut avoir besoin de lancer plusieurs instances de Tomcat en parallèle. Cela est parfaitement possible, à condition de positionner les bonnes variables d'environnement. La variable CATALINA_HOME doit pointer vers le répertoire d'installation de Tomcat. La valeur de cette variable doit être la même pour tous les contextes de lancement de chaque instance de Tomcat. Une deuxième variable est utilisée, CATALINA_BASE, qui peut prendre une valeur propre à chaque lancement. Tomcat utilise plusieurs classloader pour fonctionner. Chaque classloader charge des classes et des JAR tel que défini dans le fichier conf/catalina.properties.
  • common.loader : les classes chargées par ce classloader sont disponibles dans Tomcat et pour toutes les applications web que cette instance prend en charge.
  • server.loader : ces classes sont accessibles au niveau du serveur. Par exemple, si une connexion JDBC est définie dans le Server, c'est ce classloader qui doit charger le pilote JDBC.
  • shared.loader : ces classes sont disponibles dans toutes les applications web.
Par défaut, les classloader server et shared sont vides, et Tomcat n'utilise que le classloader common. Ensuite, Tomcat crée un classloader par application web, ce qui permet de garantir l'étanchéité complète d'une application web à l'autre. Ce classloader charge le contenu de WEB-INF/classes et WEB-INF/lib, tel que défini dans l'API Servlet. On voit donc qu'il est possible, en jouant sur la variable CATALINA_BASE de définir un jeu de classes commun aux applications web, instance par instance. Chaque instance de Tomcat peut ensuite gérer son propre environnement : les répertoires conf, work, temp, webapps et logs sont, par défaut, relatifs à CATALINA_BASE, et peuvent être redéfinis par des options dans le fichier de configuration conf/server.xml.
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