IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

 

Développons en Java   2.30  
Copyright (C) 1999-2022 Jean-Michel DOUDOUX    (date de publication : 15/06/2022)

[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

 

100. Tomcat

 

chapitre    1 0 0

 

Niveau : niveau 4 Supérieur 

 

Apache Tomcat est une implémentation open source d'un conteneur web qui permet donc d'exécuter des applications web reposant sur les technolgoies servlets et JSP.

Tomcat est diffusé en open source sous une licence Apache. C'est aussi l'implémentation de référence des spécifications servlets jusqu'à la vesion 2.4 et JSP jusqu'à la version 2.0 implémentées dans les différentes versions de Tomcat.

En tant qu'implémentation de référence de plusieurs versions des spécifications servlets/JSP, facile à mettre en oeuvre et riche en fonctionnalités, Tomcat est quasi incontournable dans les environnements de développements. Les qualités de ses dernières versions lui permettent d'être fréquemment utilisé dans des environnements de production.

Depuis la version 4, Tomcat est composé de plusieurs éléments :

  • Coyote est le connecteur pour les protocoles de communications notamment HTTP, AJP, ...
  • Catalina est le conteneur de servlets
  • Jasper est le moteur de JSP

Ce chapitre contient plusieurs sections :

 

100.1. L'historique des versions

Il existe plusieurs versions de Tomcat qui mettent en oeuvre des versions différentes des spécifications des servlets et des JSP :

Version de Tomcat

Version Servlet

Version JSP

Version EL

Version Java

3.0, 3.1, 3.2, 3.3

2.2

1.1

   

4.0, 4.1

2.3

1.2

 

1.2

5.0

2.4

2.0

2.0

1.4

6.0

2.5

2.1

2.1

1.5

7.0

3.0

2.2

2.2

1.6

8.0

3.1

2.3

3.0

1.7

9.0

4.0

2.3

3.0

1.8


Tomcat 3.x (version initiale)

  • implémente les spécifications Servlet 2.2 et JSP 1.1
  • rechargement des servlets
  • fonctionnalités HTTP de base.

Tomcat 4.x

  • implémente les spécifications Servlet 2.3 et JSP 1.2
  • nouveau conteneur de servlets Catalina
  • nouveau moteur JSP Jasper
  • le connecteur Coyote
  • utilisation de JMX,
  • application d'administration développée en Struts

Tomcat 5.x

  • implémente les spécifications Servlet 2.4 et JSP 2.0
  • performances améliorées
  • wrappers natifs pour Windows et Unix 
  • amélioration du traitement des JSP

Tomcat 5.5 nécessite un J2SE 5.0 pour fonctionner. Un module dédié permet d'utiliser Tomcat 5.5 avec un JDK 1.4 mais cela n'est pas recommandé.

Tomcat 5.5 utilise le compilateur d'Eclipse pour compiler les JSP : il n'est donc plus nécessaire d'installer un JDK pour faire fonctionner Tomcat, un JRE suffit.

La configuration de Tomcat 5.5 est différente de celle de Tomcat 5.0 sur de nombreux points

Tomcat 6.x

  • implémente la version 2.5 des spécifications des servlets (JSR-154)
  • implémente la version 2.1 des spécifications des JSP (JSR-245)
  • implémente Unified EL (Unified Expression Langage)
  • utilise Java 5
  • amélioration de l'usage mémoire

Tomcat 7.x

  • implémente la version 3.0 des spécifications des servlets
  • implémente la version 2.2 des spécifications des JSP
  • implémente Unified EL 2.2 (Unified Expression Langage)
  • utilise Java 5
  • amélioration de l'usage mémoire

Tomcat 8.x

  • implémente la version 3.1 des spécifications des servlets
  • implémente la version 2.3 des spécifications des JSP
  • implémente Unified EL 3.0 (Unified Expression Langage)

Tomcat 9.x

  • implémente la version 4.0 des spécifications des servlets

 

100.2. L'installation

Tomcat est une application écrite en Java, il est possible de l'installer et de l'exécuter sous tous les environnements disposant d'une machine virtuelle Java : un JRE, ou même un JDK pour certaines anciennes versions, est un prérequis pour permettre son exécution.

Pour les versions de Tomcat nécessitant un JDK, il faut que la variable d'environnement JAVA_HOME soit définie avec comme valeur le répertoire d'installation du JDK. Ceci permet notamment à Tomcat de trouver le compilateur Java pour compiler les JSP.

L'installation de Tomcat de façon universelle se fait simplement :

  • Tomcat est fourni dans une archive de type zip qu'il faut télécharger
  • décompresser l'archive dans un répertoire du système
  • il est préférable de définir la variable d'environnement système CATALINA_HOME qui possède comme valeur le répertoire d'installation de Tomcat

Sous Windows, Tomcat propose un package d'installation qui va permettre en plus :

  • de demander et configurer le port du connecteur http à utiliser
  • de créer une entrée dans le menu « démarrer / Programme » avec des raccourcis vers quelques fonctionnalités
  • d'exécuter Tomcat uniquement sous la forme d'un service Windows

 

100.2.1. L'installation de Tomcat 3.1 sous Windows 98

Il est possible de récupérer Tomcat sur le site d'Apache Tomcat. Il faut choisir la dernière version stable de préférence, le numéro de version et le répertoire bin pour récupérer le fichier apache-tomcat-x-y-zz.zip.

Il faut ensuite décompresser le fichier dans un répertoire du système par exemple dans C:\. L'archive est décompressée dans un répertoire nommé jakarta-tomcat

Dans une boîte DOS, assigner le répertoire contenant Tomcat à la variable d'environnement TOMCAT_HOME. Le plus simple est de l'ajouter dans le fichier autoexec.bat.

Exemple :
set TOMCAT_HOME=c:\jakarta-tomcat

Pour lancer Tomcat, il faut exécuter le fichier startup.bat dans le répertoire TOMCAT_HOME\bin

Pour vérifier que Tomcat s'exécute correctement, il faut saisir l'url http://localhost:8080 dans un browser. La page d'accueil de Tomcat s'affiche.

Le script %TOMCAT_HOME%\bin\shutdown.bat permet de stopper Tomcat.

 

100.2.2. L'installation de Tomcat 4.0 sur Windows 98

Il suffit de télécharger et d'exécuter le programme jakarta-tomcat-4.0.exe

L'assistant affiche la licence, puis permet de sélectionner les options et le répertoire d'installation.

L'assistant copie les fichiers.

Un ensemble de raccourcis est créé dans l'option "Apache Tomcat 4.0" du menu "Démarrer/Programmes".

Il faut définir la variable d'environnement système JAVA_HOME qui doit avoir comme valeur le chemin absolu du répertoire d'installation du J2SDK.

Pour la version 4.1, il faut télécharger le fichier jakarta-tomcat-4.1.40.exe sur le site http://archive.apache.org/dist/tomcat/tomcat-4/v4.1.40/bin/

 

100.2.3. L'installation de Tomcat 5.0 sur Windows

Il faut télécharger le fichier jakarta-tomcat-5.0.30.exe sur le site http://archive.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/

La version 5 utilise un programme d'installation standard guidé par un assistant qui propose les étapes suivantes :

  • la page d'accueil s'affiche, cliquez sur le bouton « Next »
  • la page d'acceptation de la licence (« Licence agreement ») s'affiche, lire la licence et si vous l'acceptez, cliquez sur le bouton « I Agree »
  • la page de sélection des composants à installer (« Choose components ») s'affiche, il faut sélectionner ou non chacun des composants ou utiliser un type d'installation qui contient une pré-configuration, cliquez sur le bouton « Next »
  • la page de sélection du répertoire d'installation (« Choose install location ») s'affiche, sélectionnez le répertoire de destination et cliquez sur le bouton « Next »
  • la page de configuration (« Basic configuration ») s'affiche et permet de définir le port du connecteur http (8080 par défaut) utilisé, le nom et le mot de passe de l'administrateur. Saisissez ces informations et cliquez sur le bouton « Next »
  • la page de sélection du chemin de la JVM (« Java Virtual Machine ») permet de sélectionner le chemin du JRE. Cliquez sur le bouton « Install »
  • l'installation s'effectue

la page de fin d'affiche. Une case à cocher permet de demander le lancement de Tomcat. Cliquez sur le bouton « Finish ».

 

100.2.4. L'installation de Tomcat 5.5 sous Windows avec l'installer

L'url pour télécharger la version 5.5 de Tomcat est  http://archive.apache.org/dist/tomcat/tomcat-5/
Attention : Tomcat 5.5 est packagé différemment de ses précédentes versions : les différents modules qui composent Tomcat sont fournis séparément. Ceci permet d'installer uniquement les modules souhaités de Tomcat notamment dans un environnement de production.
Les modules sont :

  • Core : ce module contient le serveur Tomcat
  • Deployer : ce module contient le TCD (Tomcat Client Deployer) qui utilise Ant pour compiler, valider et déployer une application web
  • Embedded : ce module contient une version embarquée de Tomcat (pour l'intégrer dans une autre application)
  • Administration web application : ce module contient l'application web d'administration de Tomcat
  • JDK 1.4 Compatibility Package : ce mode doit être utilisé pour exécuter Tomcat 5.5 avec un JDK 1.4
  • Documentation : ce module contient la documentation seule (ce module est inclus dans le module Core)

Téléchargez le setup de la dernière version de Tomcat 5.5 (par exemple apache-tomcat-5.5.23.exe) et exécutez ce fichier.

Attention : l'outil d'installation ne permet que l'exécution de Tomcat sous la forme d'un service Windows.

Cliquez sur le bouton « Next ».

Lisez la licence et si vous l'acceptez cliquez sur le bouton « I Agree ».

Cette page permet de sélectionner les composants à installer en sélectionnant le type d'installation. Le type custom permet une sélection de chaque composant.

Le composant « Service Startup » permet de demander le démarrage automatique du service Tomcat.

Le composant « Native » permet d'installer certaines librairies natives.

Le composant « Start Menu Items » permet de créer une entrée dans le menu « Démarrer / Programme » avec des raccourcis vers certaines fonctionnalités.

Sélectionnez le type d'installation, les composants à installer si besoin et cliquez sur le bouton « Next ».

Cette page permet de sélectionner le répertoire d'installation.

Sélectionnez un autre répertoire si besoin et cliquez sur le bouton « Next ».

Cette page permet de préciser le port du connecteur http à utiliser (8080 par défaut)  et de préciser les informations de login de l'administrateur de Tomcat.

La page suivante permet de préciser le chemin du JRE 5.0 minimum à utiliser.

Cliquez sur le bouton « Install » pour démarrer l'installation de Tomcat.

Cliquez sur le bouton « Finish ».

L'installation des autres modules de Tomcat se fait en les décompressant dans le répertoire d'installation mais en s'assurant que le serveur est arrêté.

 

100.2.5. L'installation Tomcat 6.0 sous Windows avec l'installer

La procédure est similaire à celle de la version 5.5 de Tomcat.
L'url pour télécharger la version 6.0 de Tomcat est https://tomcat.apache.org/download-60.cgi
Exécutez le fichier téléchargé, par exemple apache-tomcat-6.0.10.exe

L'installation se fait par un assistant sur les pages :

  • « Welcome to Apache Tomcat Setup Wizard », cliquez sur le bouton « Next »
  • « Licence Agreement », lisez la licence et si vous l'acceptez cliquez sur le bouton « I Agree »
  • « Choose Components », sélectionnez les éléments à installer et cliquez sur le bouton « Next »
  • « Choose Install Location », cliquez sur le bouton « Next »
  • « Configuration », modifier au besoin le numéro de port du connecteur http (qui sera donc utilisé dans les url) et les informations de login de l'administrateur puis cliquez sur le bouton « Next »
  • « Java Virtual Machine », cliquez sur le bouton « Install »
  • « Completing the Apache Tomcat Setup Wizard », cliquez sur le bouton Finish

 

100.2.6. La structure des répertoires

Le répertoire d'installation de Tomcat contient plusieurs répertoires.

 

100.2.6.1. La structure des répertoires de Tomcat 4

L'arborescence du répertoire d'installation de Tomcat est la suivante :

  • bin : contient un ensemble de scripts pour la mise en oeuvre de Tomcat
  • common : le sous-répertoire lib contient les bibliothèques utilisées par Tomcat et mises à disposition de toutes les applications qui seront exécutées dans Tomcat
  • conf : contient des fichiers de propriétés notamment les fichiers server.xml, tomcat-users.xml et le fichier par défaut web.xml
  • logs : contient les journaux d'exécution
  • server : contient des bibliothèques utilisées par Tomcat et l'application web d'administration de Tomcat
  • temp : est un répertoire temporaire utilisé lors des traitements
  • webapps : contient les applications web exécutées sous Tomcat
  • work : contient le résultat de la compilation des JSP en servlets

 

100.2.6.2. La structure des répertoires de Tomcat 5

Le répertoire d'installation de Tomcat 5.x contient plusieurs répertoires :

  • bin : scripts et exécutables pour gérer Tomcat
  • common : bibliothèques et classes communes pour Catalina et les applications web
  • conf : fichiers de configurations
  • logs : journaux de Catalina et des applications web
  • server : bibliothèques et classes utilisées uniquement par Catalina
  • shared : bibliothèques et classes partagées par les applications web
  • temp : répertoire de stockage de fichiers temporaires
  • webapps : répertoire de déploiement des applications web
  • work : répertoire de travail (répertoires et fichiers notamment pour la compilation des JSP)

Le répertoire conf contient en standard plusieurs fichiers de configuration :

Fichier

Rôle

catalina.policy

 

catalina.properties

Configuration du chargement des classes par Tomcat

context.xml

Configuration par défaut utilisée par tous les contextes

logging.properties

Configuration des logs de Tomcat

server.xml

Configuration du serveur Tomcat

tomcat-users.xml

Contient les données utiles pour l'authentification et pour les habilitations (user et rôle)

web.xml

Descripteur de déploiement par défaut utilisé pour toutes les applications web avant de traiter le fichier des applications


Le répertoire logs est le répertoire par défaut des logs. Sa taille ne fait que croître : il est donc nécessaire de la surveiller notamment dans un environnement de production.

Remarque : l'utilisation du répertoire shared pour mettre des bibliothèques ou des classes est déconseillée. C'est une particularité de Tomcat : il est préférable d'utiliser le répertoire WEB-INF/classes pour les classes et WEB-INF/lib pour les bibliothèques de la webapp car c'est le standard.

 

100.2.6.3. La structure des répertoires de Tomcat 6

La structure des répertoires est similaire à celle de Tomcat 5 hormis pour les répertoires shared et server qui sont remplacés par un unique répertoire lib. Ce répertoire lib ne contient pas de sous-répertoire lib et classes : il contient directement les bibliothèques.

 

100.3. L'exécution de Tomcat

Le lancement de Tomcat s'effectue en utilisant un script fourni dans le sous-répertoire d'installation de Tomcat. Sous Windows, il est possible de lancer Tomcat sous la forme d'un service.

 

100.3.1. L'exécution sous Windows de Tomcat 4.0

Sous Windows, pour lancer Tomcat manuellement, il faut exécuter la commande startup.bat dans le sous-répertoire bin du répertoire où est installé Tomcat. La commande shutdown.bat permet inversement de stopper l'exécution de Tomcat.

Par défaut, le serveur web intégré dans Tomcat utilise le port 8080 pour recevoir les requêtes HTTP. Pour vérifier la bonne installation de l'outil, il suffit d'ouvrir un navigateur et de demander l'URL : http://localhost:8080/

 

100.3.2. L'exécution sous Windows de Tomcat 5.0

En utilisant les scripts startup et shutdown

Pour lancer Tomcat, il faut d'exécuter le script startup.bat du sous-répertoire bin.

Pour arrêter Tomcat, il suffit d'exécuter le script shutdown.bat du sous-répertoire bin.

Pour une utilisation en ligne de commandes (sans IDE pour piloter Tomcat), il est pratique de créer un lien vers ces deux scripts, par exemple sur le bureau. L'avantage de les mettre sur le bureau est qu'il est possible de leur assigner des raccourcis clavier.

 

En utilisant l'application tomcat5.exe

En lançant le programme bin/Tomcat5.exe du répertoire d'installation de Tomcat, Tomcat est lancé sous la forme d'un service : les messages de la console sont affichés dans la boîte DOS associée au processus.

Tomcat apparaît dans les processus du gestionnaire de tâches.

Pour arrêter Tomcat dans ce cas, il faut fermer la fenêtre Dos : le serveur sera arrêté proprement.

En utilisant Tomcat en tant que service Windows

Le programme d'installation de Tomcat fourni un utilitaire supplémentaire qui permet d'exécuter et de gérer Tomcat en tant que service Windows.

En lançant le programme bin/tomcat5w.exe du répertoire d'installation de Tomcat, une application qui permet de configurer et de gérer l'exécution de Tomcat sous la forme d'un service Windows est lancée.

Cette application permet de gérer Tomcat en tant que service Windows.

L'onglet « General » permet de gérer l'exécution de Tomcat sous la forme d'un service.

Pour gérer le statut du service de Tomcat, il suffit d'utiliser le bouton correspondant.

Les autres onglets permettent de préciser des paramètres d'exécution de Tomcat.

Après le démarrage de Tomcat, une icône apparaît dans la barre d'icône

Elle possède un menu contextuel qui permet de réaliser plusieurs actions :

Pour arrêter Tomcat lorsqu'il est démarré de cette façon, il faut cliquer sur le bouton « Stop » dans l'onglet « General »

  • « Open Console Monitor » : permet d'afficher un journal des messages émis par Tomcat



  • « About » : permet d'afficher la licence de Tomcat
  • « Properties » : permet de changer les propriétés de Tomcat
  • L'onglet « Service » permet de préciser les informations générales concernant l'exécution de Tomcat
     


  • L'onglet Java VM permet de préciser les options utilisées lors du lancement de la JVM dans laquelle Tomcat s'exécute



  • L'onglet « Standard Streams » permet de préciser la localisation des fichiers de logs



  • « Shutdown » : permet d'arrêter le service Tomcat

 

100.3.3. La vérification de l'exécution

Pour vérifier la bonne exécution du serveur, il suffit d'ouvrir un navigateur et de saisir dans une url la machine hôte et le port d'écoute du connecteur http de Tomcat

Exemple :

Si Tomcat ne démarre pas :

  • consulter les logs pour déterminer l'origine du problème
  • lancer Tomcat en utilisant le script Startup.bat dans une console DOS pour afficher les logs
  • vérifier que le port utilisé n'est pas déjà utilisé par un autre service ou serveur

Si Tomcat est lancé mais que la page d'accueil ne s'affiche pas dans le navigateur :

  • il faut vérifier l'url saisie (nom de l'hôte et surtout le numéro du port qui doit correspondre à celui configuré dans le fichier server.xml).
  • si un proxy est utilisé, inhiber l'utilisation de se dernier pour l'url utilisée notamment en local

 

100.4. L'architecture

L'architecture de Tomcat est composée de plusieurs éléments :

  • Server
    Le serveur encapsule tout le conteneur web. Il ne peut s'exécuter qu'un seul Server dans une JVM
  • Service
    Un service regroupe des connectors et un unique engine
  • Connector
    Un connector gère les communications avec un client. Tomcat propose plusieurs connecteurs notamment Coyote pour les communications par le protocole http, JK2 pour les communications par le protocole AJP
  • Engine
    Un Engine traite les requêtes des différents Connector associés au Service : c'est le moteur de traitements des servlets.
  • Host
    Un Host est un nom de domaine dont les requêtes sont traitées par Tomcat. Un Engine peut contenir plusieurs Host.
  • Context
    Un contexte permet l'association d'une application web à un chemin unique pour un Host. Un Host peut avoir plusieurs contextes

Pour assurer ces fonctionnalités, Tomcat utilise aussi différents types de composants qui prennent en charge des fonctionnalités particulières :

  • Valve
    Une valve est une unité de traitements qui est utilisée lors du traitement de la requête. Son rôle est similaire à celui des filtres pour les servlets.
  • Logger
    Un Logger assure la journalisation des événements des différents éléments
  • Realm
    Un Realm assure l'authentification et les habilitations pour un Engine

 

100.4.1. Les connecteurs

Qu'il soit utilisé standalone ou en association avec un serveur web, Tomcat doit communiquer avec le monde extérieur.

En mode Standalone, le connecteur mis en oeuvre utilise HTTP ou HTTPs pour communiquer.

En association avec un serveur web (Apache par exemple), ce dernier s'occupe des ressources statiques (page HTML, CSS, JavaScript, images,...) et Tomcat s'occupe des ressources dynamiques (JSP, servlets, ...).

Généralement pour des applications à usage externe, l'utilisation d'un serveur web et de Tomcat se fait dans une architecture réseau sécurisée grâce à une DMZ.

Exemple :

Le module mod_jk est utilisé pour assurer la communication entre le serveur Web (Apache par exemple) et Tomcat en utilisant le protocole AJP13.

 

100.4.2. Les services

Un service regroupe des connecteurs et l'engine. Par défaut Tomcat propose un seul service nommé Catalina.

Plusieurs services peuvent être définis dans un serveur Tomcat.

 

100.5. La configuration

La configuration de Tomcat est stockée dans plusieurs fichiers dans le sous-répertoire conf. Le fichier de configuration principal est le fichier server.xml.

 

100.5.1. Le fichier server.xml

Tomcat est configuré grâce à un fichier xml nommé server.xml dans le répertoire conf.

La structure du document xml contenu dans le fichier server.xml reprend la structure de l'architecture de Tomcat :

Exemple :
 <Server>
  <GlobalNamingResources/>
  <Service>
   <Connector/>
   <Engine>
    <Host/>
   </Engine>
  </Service>
 </Server>

Remarque : il n'est pas possible d'utiliser un fichier server.xml de Tomcat 4 dans Tomcat 5.

 

100.5.1.1. Le fichier server.xml avec Tomcat 5

Le tag <Server> est le tag racine du fichier server.xml : il encapsule le serveur Tomcat lui-même. Il possède plusieurs attributs :

Attribut

Rôle

port

port sur lequel Tomcat écoute pour son arrêt (par défaut le port 8005)

shutdown

message à envoyer sur le port pour demander l'arrêt de Tomcat (par défaut SHUTDOWN)


Remarque : Tomcat refuse toute connexion sur le port d'arrêt sauf celle issue de la machine locale (exemple : telnet localhost 8005).

Le tag <Server> peut avoir un unique tag fils <GlobalNamingResources>, au moins un tag fils <Service> et éventuellement plusieurs tags fils <Listener>.

Le tag  <GlobalNamingResources/>.
Ce tag encapsule des déclarations de ressources JNDI globales au serveur.

Exemple :
   <GlobalNamingResources>
    <Environment
     name="simpleValue"
     type="java.lang.Integer"
     value="30"/>
   <Resource
    auth="Container"
    description="User database that can be updated and saved"
    name="UserDatabase"
     type="org.apache.catalina.UserDatabase"
     pathname="conf/tomcat-users.xml"
     factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/>
   <Resource
    name="jdbc/MonAppDS"
    type="javax.sql.DataSource"
    password=""
     driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
    maxIdle="2"
    maxWait="5000"
    username="APP"
    url="jdbc:derby:C:/Program Files/Java/jdk1.6.0/db/MaBaseDeTest"
    maxActive="4"/>
   </GlobalNamingResources>

Le tag <Service> encapsule un service. Ce tag possède un seul attribut :

Attribut

Rôle

name

obligatoire : nom identifiant le service (par défaut Catalina)


Plusieurs services peuvent être définis dans un server : dans ce cas, chaque service doit avoir un attribut name distinct.

Le tag <Service> doit avoir au moins un tag fils <Connector> et un unique tag fils <Engine>.

Le tag <Connector/> encapsule un connecteur. Un Connector se charge des échanges entre un client et le serveur pour un protocole donné. Ce tag possède plusieurs attributs :

Attribut

Rôle

className

nom de la classe d'implémentation du connector

protocol

protocole utilisé par le connecteur http ou AJP (par défaut HTTP/1.1). Pour utiliser le protocole AJP, il faut utiliser la valeur AJP/1.3

port

port d'écoute du connector (par défaut 8080 pour le protocole http et 8009 pour le protocole AJP13

redirectPort

sur un connector http, précise le port vers lequel les requêtes HTTPS seront redirigées

minSpareThreads

 

maxSpareThreads

 

maxThreads

nombre maximum de threads lancés pour traiter les requêtes

secure

positionné à true pour utiliser le protocole HTTPS (par défaut false)

enableLookups

effectue une résolution de l'adresse IP en nom de domaine dans les logs (par défaut true)

proxyName

 

proxyPort

 

acceptCount

Nombre maximum de requêtes mises en attente si aucun thread n'est libre

connectionTimeout

timeout en millisecondes durant lequel une requête peut rester sans être traitée

disableUploadTimeout

 

address

adresse IP des requêtes à traiter


Le tag <Engine> encapsule le moteur de servlet. Ce tag possède plusieurs attributs :

Attribut

Rôle

name

obligatoire : nom identifiant le moteur (par défaut Catalina)

defaultHost

obligatoire : hôte utilisé par défaut si l'hôte de la requête n'est pas défini dans le serveur

jvmRoute

utilisé dans le cadre d'un cluster de serveurs Tomcat pour échanger des informations notamment celles des sessions


Le tag <Engine> doit avoir au moins un tag fils <Host> et peut avoir un tag fils unique <Logger>, <Realm>, <Valve> et <DefaultContext> :

Exemple :
 <Engine defaultHost="localhost" name="Catalina">
  <Realm ... />
  <Host ... />
 </Engine>

Le tag <Host> défini un hôte virtuel sur le serveur. Ce tag possède plusieurs attributs :

Attribut

Rôle

name

obligatoire : nom de l'hôte

appBase

obligatoire : chemin par défaut pour les webapps de l'hôte. Ce chemin peut être absolu ou relatif au répertoire d'installation de Tomcat

defaultHost

hôte utilisé par défaut si l'hôte de la requête n'est pas défini dans le serveur

autoDeploy

active le déploiement automatique des webapps. True par défaut


Exemple :
  <Host appBase="webapps" name="localhost" autoDeploy="false">
  </Host>

Le tag <Context> défini un contexte d'application. Ce tag possède plusieurs attributs, notamment :

Attribut

Rôle

docBase

obligatoire : chemin du répertoire ou de l'archive de l'application. Ce chemin peut être absolu ou relatif à l'attribut appBase du Host

reloadable

demande le rechargement automatique des classes modifiées (par défaut false)

 

100.5.1.2. Les valves

Une valve est une unité de traitements qui est utilisée lors du traitement de la requête. Son rôle est similaire à celui des filtres pour les servlets.

Une valve est déclarée dans le fichier de configuration grâce au tag <valve> qui peut être utilisé comme fils des tags <engine>, <host> et <context>.

Elle se présente sous la forme d'une classe qui implémente l'interface org.apache.catalina.Valve. Cette classe est précisée dans l'attribut className

Tomcat propose plusieurs Valves par défaut :

Valve

Rôle

org.apache.catalina.valves.AccessLogValve

Configuration des logs 

org.apache.catalina.authenticator.SingleSignOn

Utilisation du SSO

 

100.5.2. La gestion des rôles

Par défaut dans Tomcat, les rôles sont définis dans le fichier tomcat-users.xml. Ce fichier permet de définir des rôles et de les associer à des utilisateurs.

La modification du fichier tomcat-users.xml peut se faire directement sur le fichier ou par l'application d'administration.

Exemple :
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
 <role rolename="tomcat"/>
 <role rolename="manager"/>
 <role rolename="test"/>
 <role rolename="admin"/>
 <user username="tomcat" password="tomcat" roles="tomcat"/>
 <user username="jm" password="jm" roles="test"/>
 <user username="admin" password="baron" roles="admin,manager"/>
</tomcat-users>

Remarque : pour utiliser l'application d'administration ou le manager, il est nécessaire de définir les utilisateurs admin et manager.

 

100.6. L'outil Tomcat Administration Tool

Tomcat Administration Tool est une application web qui permet de faciliter la configuration de Tomcat : il permet de modifier certains fichiers de configuration au moyen d'une interface graphique.

Remarque : cet outil n'est plus disponible à partir de Tomcat 6.

Il permet notamment de gérer :

  • Les connecteurs et les ports
  • Les contextes d'applications
  • Les ressources
  • La sécurité
  • Les utilisateurs

Remarque : à partir de Tomcat 5.5, cet outil n'est plus fourni en standard avec Tomcat et doit être téléchargé séparément et installé.

Dans ce cas, il faut télécharger le module et le décompresser dans le répertoire d'installation de Tomcat après avoir arrêté le serveur Tomcat.

Pour lancer l'application, il suffit de cliquer sur le lien « Tomcat Administration » sur la page d'accueil de Tomcat

Il faut saisir le user et le mot de passe définis pour le user admin (informations fournies au programme d'installation sous Windows)

Les différents éléments configurables sont présentés sous une forme arborescente dans la partie de gauche. La partie de droite permet de modifier les données de l'élément sélectionné. La liste déroulante « Actions » permet de réaliser des actions en fonction du contexte (création d'éléments, suppression, ...). Le bouton « Save » permet d'enregistrer les modifications en locale : il faut l'utiliser avant de changer de page.

Attention : Il est très important pour valider les modifications de cliquer sur le bouton « Commit changes » : cette action rend persistantes les modifications en les écrivant dans les fichiers de configuration de Tomcat.

 

100.6.0.1. La gestion des utilisateurs, des rôles et des groupes

La partie « User Definition » de l'outil d'administration permet de gérer les users, les rôles et les groupes sans avoir à modifier directement le contenu du fichier tomcat-users.xml.

Pour modifier un user, il suffit de cliquer sur son lien.

 

100.6.1. La création d'une DataSource dans Tomcat

Le plus simple est d'utiliser l'application d'administration.

Cliquez sur « Data Sources » dans l'arborescence « Resources ». Dans la liste déroulante « DataSource Actions », sélectionnez « Create New Data Source ».

Saisissez les informations nécessaires à la Datasource : le nom JNDI, l'url, la classe du pilote, le user, le mot de passe, ...

Cliquez sur le bouton « Save » puis sur « Commit changes » et confirmez la validation des modifications.

Dans le fichier de configuration de Tomcat server.xml, la Datasource a été ajoutée dans les ressources de GlobalNamingResources :

Exemple :
 <GlobalNamingResources>
 ... 
  <Resource
   name="jdbc/MonAppDS"
   type="javax.sql.DataSource"
   password=""
    driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
   maxIdle="2"
   maxWait="5000"
   username="APP"
   url="jdbc:derby:C:/Program Files/Java/jdk1.6.0/db/MaBaseDeTest"
   maxActive="4"/>
  </GlobalNamingResources>

 

100.7. Le déploiement des applications WEB

Pour être exécutée, une application web doit impérativement être déployée dans un conteneur de servlets même dans un environnement de développement.

Selon les spécifications des servlets depuis la version 2.2, un conteneur doit obligatoirement être capable de déployer une application web au format war. Tomcat propose aussi un support pour déployer les applications au format unpacked et propose différentes solutions pour assurer le déploiement des applications.

 

100.7.1. Déployer une application web avec Tomcat 5

Une application web peut être déployée sous Tomcat 5 de plusieurs manières :

  • copier l'application dans le répertoire webapps
  • définir un contexte
  • utiliser l'outil Tomcat Manager
  • utiliser les tâches Ant du Manager
  • utiliser l'outil TCD

 

100.7.1.1. Déployer une application au lancement de Tomcat

Alors que Tomcat est arrêté, il suffit de copier le répertoire contenant la webapp ou le fichier war qui la contient dans le sous-répertoire webapps de Tomcat et de redémarrer ce dernier.

Par défaut, l'uri de l'application utilisera le nom du répertoire ou du fichier war : Tomcat va créer un contexte pour l'application en lui associant comme chemin de contexte le nom du répertoire ou du fichier war sans son extension.

Par défaut, Tomcat décompresse le contenu d'un fichier war dans un répertoire portant le nom du fichier war sans son extension.

Pour redéployer une application sous la forme d'un fichier war, il est préférable de supprimer le répertoire contenant l'application décompressée.

Les applications du répertoire webapps sont automatiquement déployées au démarrage si l'attribut deployOnStartUp du tag Host vaut true.

 

100.7.1.2. Déployer une application sur Tomcat en cours d'exécution

Si l'attribut autoDeploy du tag Host vaut true, le déploiement de l'application par copie dans le répertoire webapps peut se faire alors que Tomcat est en cours d'exécution. Ce mécanisme permet aussi de recharger dynamiquement une application.

Remarque : Tomcat propose des fonctionnalités de rechargement dynamique d'une application ayant subi des modifications : il est cependant préférable de redémarrer le serveur Tomcat pour éviter certains écueils.

 

100.7.1.3. L'utilisation d'un contexte

Un descripteur de contexte est un document au format xml qui contient la définition d'un contexte.

Ce descripteur permet de configurer le contexte.

Ce fichier doit être placé dans le sous-répertoire /conf/{engine_name}/{host_name} où {engine_name} est le nom du moteur  et {host_name} est le nom de l'hôte.

Avec la configuration par défaut de Tomcat, c'est le sous-répertoire /conf/catalina/localhost.

Le contenu de ce descripteur de contexte est détaillé dans une des sections suivantes de ce chapitre.

 

100.7.1.4. Déployer une application avec le Tomcat Manager

Tomcat fournit l'application web Tomcat Manager pour permettre la gestion des applications web exécutées sur le serveur sans avoir à procéder à un arrêt/redémarrage de Tomcat.

Son utilisation est détaillée dans une des sections suivantes de ce chapitre.

 

100.7.1.5. Déployer une application avec les tâches Ant du Manager

Tomcat propose des tâches Ant qui permettent l'utilisation dans des scripts de certaines fonctionnalités du Manager.

L'utilisation de ces tâches Ant est détaillée dans la documentation de Tomcat.

 

100.7.1.6. Déployer une application avec le TCD

L'outil TCD (Tomcat Client Deployer) permet de packager une application et de gérer son cycle de vie dans le serveur Tomcat. Cet outil utilise les tâches Ant du Manager.

Son utilisation est détaillée dans une des sections suivantes de ce chapitre.

 

100.8. Tomcat pour le développeur

 

100.8.1. Accéder à une ressource par son url

Une url permet  d'accéder aux ressources statiques et dynamiques d'une application web. Par exemple dans une application contenue dans le sous-répertoire maWebApp du répertoire webapps de Tomcat, l'accès aux ressources se fera avec une url de la forme :

http://host[:port]/webapp/chemin/ressource

Exemple :

http://localhost:8080/maWebApp

Pour une ressource statique, il suffit de préciser le chemin dans la webapp et le nom de la ressource.

Exemple : pour le fichier index.htm à la racine de la webapp.

http://localhost:8080/maWebApp/index.htm

Exemple : pour le fichier index.htm dans le sous-répertoire admin de la webapp.

http://localhost:8080/maWebApp/admin/index.htm

Pour les ressources dynamiques de type servlet, le chemin et la ressource doivent correspondre au mapping qui est fait entre la classe et l'url dans le fichier de configuration web.xml.

Exemple : mapping de la servlet fr.jmdoudouxmawebapp.AfficherListeServ vers l'url  AfficherListe
 <?xml version="1.0" encoding="ISO-8859-1"?>
 <web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
	 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
   version="2.4">
  <servlet>
    <servlet-name>AffListe</servlet-name>
    <servlet-class>fr.jmdoudouxmawebapp.AfficherListeServ</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>AffListe</servlet-name>
    <url-pattern>/AfficherListe</url-pattern>
  </servlet-mapping>
 </web-app>

Exemple : appel de la servlet AfficherListeServ.

http://localhost:8080/maWebApp/AfficherListe

Attention : Tomcat 5 vérifie le fichier de configuration de chaque webapp (WEB-INF/web.xml) et impose que l'ordre des tags dans ce fichier corresponde à celui défini dans la DTD du fichier web.xml.

 

100.8.2. La structure d'une application web et format war

Depuis la spécification 2.2 des servlets, le contenu d'une webapp doit obligatoirement respecter une certaine structure pour organiser ses répertoires et ses fichiers :

  • les ressources statiques sont stockées à la racine de la webapp ou dans un de ses sous-répertoires autre que les répertoires WEB-INF et META-INF. Ces deux répertoires ne sont accessibles que par le conteneur
  • le fichier de configuration server.xml est stocké dans le répertoire WEB-INF
  • les ressources utilisées par le conteneur doivent être le répertoire WEB-INF et, notamment, son sous-répertoire classes (pour les classes comme les servlets et les ressources associées comme les fichiers .properties) et son sous-répertoire lib pour les bibliothèques (pilote JDBC, API, framework, ...)

Le format war est physiquement une archive de type zip qui englobe le contenu de la webapp.

Pour déployer une webapp dans Tomcat, il suffit de copier le répertoire de la webapp (forme unpacked) ou son fichier war (forme packed) dans le sous-répertoire webapps.

Il est aussi possible de définir un contexte dont l'attribut docbase a pour valeur un répertoire quelconque du système de fichiers. Il est alors possible de développer l'application en dehors de Tomcat et d'utiliser ce répertoire de développement comme répertoire de déploiement.

Les classes et bibliothèques contenues dans les répertoires WEB-INF/classes et WEB-INF/lib sont utilisables par les classes de l'application.

 

100.8.3. La configuration d'un contexte

Un contexte  est défini pour chaque application web exécutée sur le serveur soit explicitement dans la configuration soit implicitement avec un contexte par défaut créé par Tomcat.

 

100.8.3.1. La configuration d'un contexte avec Tomcat 5

Un contexte peut être défini explicitement de plusieurs manières :

  • dans le fichier conf/server.xml (depuis la version 5 de Tomcat, cette utilisation n'est pas recommandée)
  • dans un fichier xml de configuration du contexte
  • dans le fichier META-INF/context.xml de la webapp

Les contextes peuvent être modifiés manuellement en modifiant le fichier de configuration adéquat ou en utilisant l'outil d'administration de Tomcat

Un contexte est défini grâce à un tag <Context> qui possède plusieurs attributs :

  • path : précise le chemin de contexte de l'application. Il doit commencer par un / et être unique pour chaque hôte
  • docbase : précise le chemin absolu ou relatif au sous-répertoire webapps du répertoire de l'application web ou le chemin de son fichier .war
  • reloadable : précise si l'application doit être rechargée automatiquement en cas de modification dans les sous-répertoires WEB-INF/Classes et WEB-INF/lib
  • crossContext : précise si l'application peut avoir accès au contexte des autres applications exécutées en utilisant la méthode getContext() de la classe ServletContext (false par défaut).
  • cookies : précise si les cookies sont utilisés pour échanger l'id de session (true par défaut). Pour forcer l'utilisation de la réécriture d'url, il faut donner la valeur false à cet attribut
  • privileged : précise si l'application peut avoir accès aux servlets du conteneur

L'implémentation par défaut de l'interface Context fournie avec Tomcat (org.apache.catalina.core.StandardContext) propose plusieurs attributs supplémentaires dont :

  • workdir : précise le répertoire temporaire de travail
  • unpackWar : précise si le fichier war doit être décompressé (true par défaut)

Un fichier de configuration du contexte peut être défini dans le répertoire conf/nom_engine/nom_hôte/. Son nom sera utilisé (dans son extension .xml) par défaut comme chemin de contexte.

La définition d'un contexte est par exemple utilisée par Sysdeo dans son plug-in Eclipse pour faciliter l'utilisation de Tomcat.

 

100.8.4. L'invocation dynamique de servlets

Tomcat propose une fonctionnalité particulière nommée « Invoker servlet » qui permet l'appel d'une servlet sans que celle-ci soit déclarée dans un fichier web.xml.

Cette fonctionnalité peut être pratique dans un environnement de développement. Il ne faut pas l'utiliser pour d'autre besoin que celui de tests, surtout, elle ne doit pas être activée en production.

Pour activer cette fonctionnalité, il faut décommenter la déclaration de la servlet Invoker et son mapping dans le fichier de configuration par défaut des applications web. Ce fichier est le fichier /conf/web.xml.

La déclaration est faite par le tag <servlet>.

Exemple :
 <servlet>
    <servlet-name>invoker</servlet-name>
   <servlet-class>
    org.apache.catalina.servlets.InvokerServlet
   </servlet-class>
   <init-param>
      <param-name>debug</param-name>
      <param-value>0</param-value>
   </init-param>
    <load-on-startup>2</load-on-startup>
 </servlet>

Le mapping est fait par le tag <servlet-mapping>

Exemple :
  <servlet-mapping>
    <servlet-name>invoker</servlet-name>
    <url-pattern>/servlet/*</url-pattern>
  </servlet-mapping>

Il faut enregistrer le fichier modifié et redémarrer Tomcat.

Il suffit d'écrire le code de la servlet, de la compiler et de mettre le fichier .class correspondant dans le sous-répertoire WEB-INF/Classes d'une webapp.

Exemple :
package fr.jmdoudoux.dej;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloServlet extends javax.servlet.http.HttpServlet implements
   javax.servlet.Servlet {

  public HelloServlet() {
   super();
  }
  protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
   response.setContentType("text/html");
   PrintWriter out = response.getWriter();
   out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 "
     + "Transitional//EN\">\n"
     + "<HTML>\n"
     + "<HEAD><TITLE>Hello</TITLE></HEAD>\n"
     + "<BODY>\n"
     + "<H1>Hello</H1>\n"
     + "</BODY></HTML>");
  }
 }

Pour lancer la servlet, il suffit d'ouvrir l'url http://host:port/webapp/servlet/nom_pleinement_qualifié_de_la_classe

Attention : avec Tomcat 6, il est nécessaire de positionner l'attribut privileged à true pour le contexte de l'application.

 

100.8.5. Les bibliothèques partagées

Tomcat propose une solution pour partager des bibliothèques communes à toutes les applications qui s'exécutent sur le serveur.

Attention l'utilisation de cette fonctionnalité est spécifique à Tomcat. Il est en général préférable de mettre les bibliothèques dans le répertoire WEB-INF/lib de chaque application. Les bibliothèques sont dupliquées dans chaque application mais cela permet de rendre les applications moins dépendantes de Tomcat en plus d'offrir à chaque application la possibilité d'utiliser une version de bibliothèque différente.

 

100.8.5.1. Les bibliothèques partagées sous Tomcat 5

Deux répertoires sont fournis à cet effet :

  • Le sous-répertoire common/lib : les bibliothèques sont partagées avec Tomcat et toutes les applications
  • Le sous-répertoire shared/lib : les bibliothèques sont partagées par toutes les applications mais ne sont pas accessibles pour Tomcat

Des répertoires nommés classes permettent de façon similaire de partager des classes non regroupées dans une archive (jar ou zip).
 

Par défaut, Tomcat 5 fournit plusieurs bibliothèques partagées notamment celles des servlets, JSP et EL utilisables par toutes les webapp qu'il exécute. Ces API sont dans le répertoire "common/lib" ou "shared/lib" de Tomcat :

  • ant.jar (Apache Ant 1.6)
  • commons-collections*.jar (Commons Collections 2.1)
  • commons-dbcp.jar (Commons DBCP 1.1)
  • commons-el.jar (Commons Expression Language 1.0)
  • commons-logging-api.jar (Commons Logging API 1.0.3)
  • commons-pool.jar (Commons Pool 1.1)
  • jasper-compiler.jar
  • jsp-api.jar (JSP 2.0)
  • commons-el.jar (JSP 2.0 EL)
  • naming-common.jar
  • naming-factory.jar
  • naming-resources.jar
  • servlet-api.jar (Servlet 2.4)

 

100.9. Le gestionnaire d'applications (Tomcat manager)

Tomcat fournit une application web pour permettre la gestion des applications web exécutées sur le serveur sans avoir à procéder à un arrêt/redémarrage de Tomcat.

Cette application permet de :

  • Lister les applications déployées avec leur état et le nombre de sessions ouvertes
  • Déployer une nouvelle application (deploy)
  • Arrêter (stop), démarrer (start) et recharger une application (reload)
  • Supprimer une application (undeploy)
  • Obtenir des informations sur la JVM et l'OS

L'application Manager peut être utilisée de trois manières :

  • Utilisation de l'interface graphique est associée au contexte /manager. Elle peut être lancée en utilisant le lien « Tomcat Manager » sur la page d'accueil de Tomcat ou en utilisant l'uri /manager/html
  • Utilisation de requêtes http : les opérations sont fournies dans la requête. Cette solution permet son utilisation dans des scripts
  • Utilisation de tâches Ant

 

100.9.1. L'utilisation de l'interface graphique

Le manager de Tomcat est un outil web de Tomcat qui permet de gérer les applications exécutées sous Tomcat. Elle est fournie en standard lors de l'installation de Tomcat.

L'utilisation du manager est soumise à une authentification préalable avec un utilisateur possédant le rôle de manager. Ceci est configuré dans le fichier /conf/tomcat-users.xml.

Par défaut, aucun utilisateur ne possède ce rôle : il est donc nécessaire de l'ajouter.

Sous Windows, avec le programme d'installation, l'utilisateur saisi est associé aux rôles admin et manager.

Par défaut, Tomcat utilise un MemoryRealm pour l'authentification. Dans ce cas, pour ajouter ou modifier les utilisateurs et leurs rôles, il faut modifier le fichier /conf/tomcat-users.xml.

Le tag <role> permet de définir un rôle. Par exemple, il faut ajouter le rôle manager si ce dernier n'est pas défini.

Le tag <user> permet de déclarer un utilisateur en précisant son nom avec l'attribut username, son mot de passe avec l'attribut password et en lui associant un ou plusieurs rôles avec l'attribut roles. Plusieurs rôles peuvent être donnés à un utilisateur en les séparant chacun par une virgule.

Exemple :
 <?xml version='1.0' encoding='utf-8'?>
 <tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <role rolename="manager"/>
  <role rolename="admin"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
  <user username="admin" password="admin" roles="admin,manager"/>
 </tomcat-users>

Tous les utilisateurs qui possèdent le rôle manager peuvent employer l'application Manager.

Il faut ouvrir un navigateur sur l'url du serveur Tomcat.

Cliquez sur le lien « Tomcat Manager »

Une boîte de dialogue demande l'authentification d'un utilisateur ayant un rôle de type manager. Dans l'installation par défaut, le user admin possède les rôles manager et admin.

Remarque : les informations concernant les utilisateurs sont par défaut dans le répertoire $CATALINA_HOME/conf/tomcat-users.xml.

Il est possible d'utiliser une valve pour restreindre l'accès au Tomcat Manager en fonction de l'adresse IP ou du nom d'hôte de la machine.

Exemple :
 <?xml version="1.0" encoding="UTF-8"?>
 <Context
   docBase="C:/Program Files/Apache/Tomcat 5.5/server/webapps/manager"
   privileged="true">
 ...
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
   allow="127.0.0.1"/>
 </Context>

Si une machine non référencée tente d'accéder à l'application, un message d'erreur est affiché :

Ceci permet de renforcer la sécurité notamment en production.

La page principale de l'application est composée de plusieurs parties.

La partie applications affiche la liste des applications déployées et permet de les gérer.

La partie Serveur affiche quelques informations sur les versions de Tomcat, de la JVM et de l'OS d'exécution.

La partie Deploy permet de déployer une application web soit à partir d'éléments sur le serveur ou sur le poste client.

 

100.9.1.1. Le déploiement d'une application

La partie « Deploy directory or WAR File located on Server » permet de déployer une application se trouvant déjà sur la machine.

Il faut fournir trois données :

  • le chemin du contexte, exemple : /MaWebApp
  • le nom du fichier web.xml : web.xml en général
  • le chemin où se situe l'application, exemple : C:\java\projet\MaWebApp

Puis cliquer sur le bouton « Deploy ».

La partie « War file to deploy » permet de sélectionner un fichier de type war du poste client, de le télécharger sur le serveur, de le déployer dans Tomcat et de démarrer l'application.

Exemple :

Cliquez sur « Browse », sélectionnez le fichier .war et cliquez sur « Deploy ».

Le fichier war est téléchargé dans le répertoire webapp, il est déployé par Tomcat (Tomcat est configuré par défaut pour déployer automatiquement les fichiers .war du répertoire webapp).

La liste des applications est enrichie de l'application déployée.

 

100.9.1.2. La gestion des applications

La partie applications permet de gérer le cycle de vie des applications déployées.

Il est possible d'accéder à l'application en cliquant sur le lien du chemin de l'application

Il est possible de gérer le cycle de vie de l'application en utilisant les liens de commandes :

  • arrêter l'application en cliquant sur le lien « Arrêter » de l'application correspondante.
  • démarrer l'application en cliquant sur le lien « Démarrer » de l'application correspondante.
  • recharger l'application (équivalent à un arrêt/démarrage consécutif) en cliquant sur le lien « Recharger » de l'application correspondante.
  • supprimer l'application en cliquant sur le lien « Undeploy » de l'application correspondante.

Une application arrêtée est supprimée du serveur Tomcat.

Chacune de ces actions nécessite une confirmation

Cliquez sur « Etat complet du serveur » pour obtenir des informations sur l'environnement d'exécution :

  • Version de Tomcat,
  • Information sur la JVM (version et fournisseur),
  • Informations sur le système d'exploitation et l'architecture processeur,
  • Informations sur la mémoire utilisée et disponible de la JVM,
  • Statistiques des ports utilisés par Tomcat

 

100.9.2. L'utilisation des commandes par requêtes HTTP

Comme pour l'utilisation de l'interface, l'utilisation des commandes par requêtes http nécessite une authentification préalable.

Toutes les requêtes pour exécuter une commande sont de la forme :
http://{hôte}:{port}/manager/{commande}?{paramètres}

Hôte et port représentent la machine et le port utilisés par Tomcat. Commande est la commande à exécuter avec ses éventuels paramètres.

Certaines commandes attendent un paramètre path qui précise le chemin du contexte de l'application à utiliser. La valeur de ce paramètre commence par un /.

Remarque : il n'est pas possible d'effectuer des commandes sur l'Application Manager lui-même.

L'exécution de ces commandes renvoie une réponse ayant pour type mime text/plain. Cette réponse ne contient donc aucun tag de formatage HTML ce qui permet de l'exploiter dans des scripts par exemple.

La première ligne indique l'état de l'exécution de la commande : OK ou FAIL pour indiquer respectivement que la commande a réussi ou qu'elle a échoué. Le reste de la ligne contient un message d'information ou d'erreur.

Certaines commandes renvoient des lignes supplémentaires contenant le résultat de leurs exécutions.

 

100.9.2.1. La commande list

La commande list permet de demander l'affichage de la liste des applications déployées sur le serveur :

Exemple : http://localhost:8088/manager/list
 OK - Applications listées pour l'hôte virtuel (virtual host) localhost
 /admin:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/admin
 /host-manager:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/Manager
 /tomcat-docs:running:0:tomcat-docs
 /axis:running:0:axis
 /:running:0:ROOT
 /manager:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/manager

Cette liste contient plusieurs informations séparées par des deux-points : le contexte de l'application, son statut (running ou stopped), le nombre de sessions ouvertes et le chemin de la webapp.

 

100.9.2.2. La commande serverinfo

La commande serverinfo permet d'obtenir des informations sur l'OS et la JVM.

Exemple : http://localhost:8088/manager/serverinfo
 OK - Server info
 Tomcat Version: Apache Tomcat/5.5.23
 OS Name: Windows XP
 OS Version: 5.1
 OS Architecture: x86
 JVM Version: 1.5.0-b64
 JVM Vendor: Sun Microsystems Inc.

 

100.9.2.3. La commande reload

Cette commande permet de demander le rechargement d'une webapp qui est stockée dans un sous-répertoire (déploiement sous la forme étendue).

Cette commande attend un paramètre path qui doit avoir comme valeur le contexte de la webapp.

Exemple : http://localhost:8080/manager/reload?path=/hello
OK - Application rechargée au chemin de contexte /hello
Attention : le rechargement ne concerne que les classes. Le fichier web.xml n'est pas relu : 
la prise en compte de modification dans ce fichier nécessite un arrêt/démarrage de la webapp

 

100.9.2.4. La commande resources

La commandes resources permet d'obtenir une liste des ressources JNDI globales définies dans le serveur Tomcat et pouvant être utilisées.

Exemple : http://localhost:8080/manager/resources
 OK - Liste des ressources globales de tout type
 UserDatabase:org.apache.catalina.users.MemoryUserDatabase
 jdbc/MonAppDS:org.apache.tomcat.dbcp.dbcp.BasicDataSource
 simpleValue:java.lang.Integer

Chaque ressource est précisée sur une ligne qui contient son nom et son type séparés par un deux-points.

Il est possible de préciser un type d'objet grâce au paramètre type. Dans ce cas la valeur du paramètre type doit être une classe pleinement qualifiée.

Exemple : http://localhost:8088/manager/resources?type=java.lang.Integer
 OK - Liste des ressources globales de type java.lang.Integer
 simpleValue:java.lang.Integer

 

100.9.2.5. La commande roles

Cette commande donne la liste de tous les rôles définis :

Exemple : http://localhost:8080/manager/roles
 OK - Liste de rôles de securité
 tomcat:
 role1:
 manager:
 admin:

Chaque ligne contient un rôle et sa description séparée par un caractère deux-points.

 

100.9.2.6. La commande sessions

Cette commande permet d'obtenir des informations sur les sessions d'un contexte.

Cette commande attend obligatoirement le paramètre path qui précise le chemin du contexte de l'application. Si ce paramètre n'est pas précisé, la commande renvoie une erreur.

Exemple : http://localhost:8080/manager/sessions
ECHEC - Un chemin de contexte invalide null a été spécifié

Le résultat de la commande contient :

  • Le timeout des sessions
  • Le nombre de sessions actives par tranche de timeout de 10 minutes
Exemple : http://localhost:8088/manager/sessions?path=/hello
 OK - Information de session pour l'application au chemin de contexte /hello
 Interval par défaut de maximum de session inactive 30 minutes
 30 - <40 minutes:2 sessions

 

100.9.2.7. La commande stop

Cette commande permet de demander l'arrêt d'une webapp.

Cette commande attend obligatoirement le paramètre path qui précise le chemin du contexte de l'application à arrêter. Si ce paramètre n'est pas précisé, la commande renvoie une erreur.

Exemple : http://localhost:8080/manager/stop
ECHEC - Un chemin de contexte invalide null a été spécifié

La commande renvoie son statut et un message d'information :

Exemple : http://localhost:8080/manager/stop?path=/hello
OK - Application arrétée pour le chemin de contexte /hello

 

100.9.2.8. La commande start

Cette commande permet de démarrer une webapp.

Cette commande attend obligatoirement le paramètre path qui précise le chemin du contexte de l'application à démarrer. Si ce paramètre n'est pas précisé, la commande renvoie une erreur.

Exemple : http://localhost:8080/manager/start
ECHEC - Un chemin de contexte invalide null a été spécifié

La commande renvoie son statut et un message d'information :

Exemple : http://localhost:8088/manager/start?path=/hello
OK - Application démarrée pour le chemin de contexte /hello

 

100.9.2.9. La commande undeploy

Cette commande permet de supprimer une webapp. Elle arrête préalablement l'application avant sa suppression.

Cette commande attend obligatoirement le paramètre path qui précise le chemin du contexte de l'application à supprimer. Si ce paramètre n'est pas précisé, la commande renvoie une erreur.

Exemple : http://localhost:8080/manager/undeploy
ECHEC - Un chemin de contexte invalide null a été spécifié

La commande renvoie son statut et un message d'information :

Exemple : http://localhost:8080/manager/undeploy?path=/hello
OK - Application non-déployée pour le chemin de contexte /hello

Attention : cette commande supprime tout ce qui concerne la webapp.

  • Le répertoire de déploiement de l'application s'il existe (par exemple webapps/hello)
  • Le fichier .war s'il existe (par exemple webapps/hello.war)
  • Le contexte

Si le contexte est défini dans le fichier server.xml, alors la commande échoue :

Exemple : le fichier server.xml
 <?xml version="1.0" encoding="UTF-8"?>
 <Server>
 ... 
  <Service name="Catalina">
 ...
   <Engine defaultHost="localhost" name="Catalina">
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm"/>
    <Host appBase="webapps" name="localhost">
     <Context path="/hello"></Context>
    </Host>
   </Engine>
  </Service>
 </Server>
Exemple : http://localhost:8088/manager/undeploy?path=/hello
FAIL - Context /hello is defined in server.xml and may not be undeployed

 

100.9.2.10. La commande deploy

Cette commande permet de déployer une application.

Exemple : déployer l'application dont le fichier .war est dans le répertoire de déploiement
http://localhost:8080/manager/deploy?path=/hello&war=hello.war

Exemple : déployer une application dont le répertoire de déploiement est un sous-répertoire du répertoire de déploiement de Tomcat
http://localhost:8088/manager/deploy?war=hello&path=/hello
	 
OK - Application déployée pour le chemin de contexte /hello

Remarque : cet exemple n'est utile que si l'option autoDeploy est à False dans la configuration du Host concerné. Cette commande permet de déployer une application sous la forme d'un sous-répertoire  dans le répertoire de déploiement de Tomcat, sans avoir à redémarrer Tomcat.

 

100.9.3. L'utilisation du manager avec des tâches Ant

Tomcat 5 propose un ensemble de tâches Ant qui permet d'exécuter des traitements du manager.

Comme pour toute tâche Ant externe, il faut déclarer chaque tâche à utiliser avec le tag taskdef.

Exemple :
<project name="Hello" default="list" basedir=".">
 <!-- Propriété d'accès au Manager -->
 <property name="url" value="http://localhost:8088/manager" />
 <property name="username" value="admin" />
 <property name="password" value="admin" />
 <!-- Chemin du contexte de l'application -->
 <property name="path" value="/hello" />
 <!-- Configure the custom Ant tasks for the Manager application -->
 <taskdef name="list" classname="org.apache.catalina.ant.ListTask" />
 <target name="list" description="Liste des webapp déployée">
  <list url="${url}" username="${username}" password="${password}" />
 </target>
</project>

Pour utiliser les tâches, il faut que le fichier catalina-ant.jar soit accessible par Ant. Pour cela, il y a deux solutions :
1) Dans la balise classpath de la balise taskdef

Exemple :
<project name="Hello" default="list" basedir=".">
 <property name="tomcat.home" value="C:/Program Files/Apache/Tomcat 5.5" />

 <!-- Propriété d'accès au Manager -->
 <property name="url" value="http://localhost:8088/manager" />
 <property name="username" value="admin" />
 <property name="password" value="admin" />

 <!-- Chemin du contexte de l'application -->
 <property name="path" value="/hello" />

 <!-- Configure the custom Ant tasks for the Manager application -->
  <taskdef name="list" classname="org.apache.catalina.ant.ListTask">
  <classpath>
   <path location="${tomcat.home}/server/lib/catalina-ant.jar" />
  </classpath>
 </taskdef>

 <target name="list" description="Liste des webapp déployée">
  <list url="${url}" username="${username}" password="${password}" />
 </target>
</project>

2) copier le fichier catalina-ant.jar, contenu dans le sous-répertoire server/lib du répertoire d'installation de Tomcat, dans le sous-répertoire lib du répertoire d'installation de Ant.

Résultat d'exécution :
Buildfile: C:\Documents and Settings\jmd\workspace\Tests\build.xml
list:
   [list] OK - Applications listées pour l'hôte virtuel (virtual host) localhost
   [list] /admin:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/admin
   [list] /host-manager:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/
	    host-manager
   [list] /tomcat-docs:running:0:tomcat-docs
   [list] /hello:running:0:hello
   [list] /axis:running:0:axis
   [list] /:running:0:ROOT
   [list] /manager:running:0:C:/Program Files/Apache/Tomcat 5.5/server/webapps/manager
BUILD SUCCESSFUL
Total time: 173 milliseconds

Tomcat propose plusieurs tâches :

Classe de la tâche

Rôle

org.apache.catalina.ant.InstallTask

Déployer une application

org.apache.catalina.ant.ReloadTask

Recharger une application

org.apache.catalina.ant.ListTask

Lister les applications déployées

org.apache.catalina.ant.StartTask

Démarrer une application

org.apache.catalina.ant.StopTask

Arrêter une application

org.apache.catalina.ant.UndeployTask

Supprimer une application

org.apache.catalina.ant.SessionsTask

Obtenir des informations sur la session

org.apache.catalina.ant.RôlesTask

Obtenir des informations sur les rôles

org.apache.catalina.ant.ServerInfoTask

Obtenir des informations sur le serveur

org.apache.catalina.ant.ResourcesTask

Obtenir des informations sur les ressources JNDI

org.apache.catalina.ant.JMXGetTask

Obtenir une valeur d'un MBean

org.apache.catalina.ant.JMXQueryTask

Effectuer une requête sur le serveur JMX

org.apache.catalina.ant.JMXSetTask

Mettre à jour une valeur d'un MBean


Toutes ces tâches attendent au moins trois paramètres :

  • url : url d'accès à l'application Manager
  • username : utilisateur ayant le rôle admin
  • password : mot de passe de l'utilisateur ayant le rôle admin
 

Certaines tâches attendent en plus des paramètres dédiés à leurs exécutions.

 

100.9.4. L'utilisation de la servlet JMXProxy

Tomcat propose une servlet qui fait office de proxy pour obtenir ou mettre à jour des données de MBean.

Par défaut, sans paramètre, la servlet affiche tous les MBeans.

Exemple : http://localhost:8088/manager/jmxproxy
OK - Number of results: 200

Name: Users:type=Role,rolename=role1,database=UserDatabase 
modelerType: org.apache.catalina.mbeans.RoleMBean 
rolename: role1

Name: Users:type=User,username="both",database=UserDatabase 
modelerType: org.apache.catalina.mbeans.UserMBean 
groups: [Ljava.lang.String;@16be68f 
password: tomcat 
roles: [Ljava.lang.String;@edf389 
username: both

Name: Catalina:type=Manager,path=/axis,host=localhost 
modelerType: org.apache.catalina.session.StandardManager 
algorithm: MD5 
randomFile: /dev/urandom 
className: org.apache.catalina.session.StandardManager 
distributable: false 
entropy: org.apache.catalina.session.StandardManager@a4e743 
maxActiveSessions: -1 
maxInactiveInterval: 1800 
processExpiresFrequency: 6 
sessionIdLength: 16 
name: StandardManager 
pathname: SESSIONS.ser 
activeSessions: 0 
sessionCounter: 0 
maxActive: 0 
sessionMaxAliveTime: 0 
sessionAverageAliveTime: 0 
rejectedSessions: 0 
expiredSessions: 0 
processingTime: 0 
duplicates: 0 
...

Le paramètre qry permet de préciser une requête pour filtrer les résultats :

Exemple : http://localhost:8088/manager/jmxproxy/?qry=*%3Atype=User%2c*
 OK - Number of results: 4

 Name: Users:type=User,username="both",database=UserDatabase
 modelerType: org.apache.catalina.mbeans.UserMBean
 groups: [Ljava.lang.String;@1d8c528
 password: tomcat
 roles: [Ljava.lang.String;@77eaf8
 username: both

 Name: Users:type=User,username="tomcat",database=UserDatabase
 modelerType: org.apache.catalina.mbeans.UserMBean
 groups: [Ljava.lang.String;@e35bb7
 password: tomcat
 roles: [Ljava.lang.String;@9a8a68
 username: tomcat

 Name: Users:type=User,username="role1",database=UserDatabase
 modelerType: org.apache.catalina.mbeans.UserMBean
 groups: [Ljava.lang.String;@1f4e571
 password: tomcat
 roles: [Ljava.lang.String;@1038de7
 username: role1

 Name: Users:type=User,username="admin",database=UserDatabase
 modelerType: org.apache.catalina.mbeans.UserMBean
 groups: [Ljava.lang.String;@5976c2
 password: admin
 roles: [Ljava.lang.String;@183e7de
 username: admin

La servlet permet aussi de modifier à chaud des attributs d'un MBean grâce à trois paramètres :

  • set : le nom du MBean
  • att : le nom de l'attribut à modifier
  • val : la nouvelle valeur de l'attribut

 

100.10. L'outil Tomcat Client Deployer

L'outil TCD (Tomcat Client Deployer) permet de packager une application et de gérer le cycle de vie de l'application dans le serveur Tomcat. Cet outil repose sur les tâches Ant qui utilisent le Tomcat Manager.

Il faut installer l'outil Ant :

  • Télécharger Ant
  • Décompresser le fichier obtenu
  • Ajouter le répertoire bin d'Ant dans le path du système

La variable d'environnement JAVA_HOME doit pointer sur le répertoire d'un JDK.

Il faut installer l'outil TDC en effectuant les opérations suivantes :

  • Télécharger TDC
  • Décompresser le fichier obtenu

Il faut définir un fichier deployer.properties qui va contenir des informations sur l'application à gérer et sur le serveur Tomcat. Ces informations sont fournies sous la forme de propriétés :

  • webapp : nom de l'application web
  • path : chemin de contexte de l'application
  • url : url vers le manager de Tomcat
  • username : nom de l'utilisateur ayant le rôle manager
  • password : mot de passe de l'utilisateur
  • build : répertoire de base dans lequel l'application sera compilée. L'application sera compilée dans le répertoire ${build}/webapp/${path}
Exemple :
 webapp=hello
 path=/hello
 url=http://localhost:8088/manager
 username=admin
 password=admin

Pour exécuter TCD, il faut lancer ant avec, en paramètre, la tâche à exécuter dans le répertoire qui contient le fichier build.xml.

Exemple :
 Ant start
 Ant stop
 Ant reload

Les tâches utilisables sont :

  • compile : compile et valide une application (classes et JSP). Cette tâche ne nécessite pas d'accès au serveur Tomcat. Attention : cette compilation ne peut fonctionner qu'avec la version de Tomcat correspondant à celle de l'outil
  • deploy : déploie une application dans le serveur Tomcat
  • start : démarre l'application
  • reload : rechargement de l'application
  • stop : arrêt de l'application

 

100.11. Les optimisations

Cette section présente rapidement quelques optimisations possibles dans la configuration de Tomcat notamment dans une optique d'exécution dans un environnement de production.

Il est préférable de mettre à false l'attribut enableLookups des tags <Connector> dans le fichier server.xml : ceci évite à Tomcat de déterminer le nom de domaine à partir de l'adresse IP des requêtes.

Il est préférable de remplacer les valeurs des attributs name des tags <Service> et <Engine> dans le fichier server.xml : ceci permet de les distinguer car par défaut, ils possèdent le même nom (Catalina).

L'attribut reloadable doit être à false pour chaque contexte : ceci évite à Tomcat de vérifier périodiquement le besoin de recharger les classes.

Il faut désactiver dans le fichier server.xml les connectors qui ne sont pas utilisés.

 

100.12. La sécurisation du serveur

Cette section présente rapidement quelques actions possibles pour améliorer la sécurisation d'un serveur Tomcat notamment dans une optique d'exécution dans un environnement de production. Ces actions ne concernent que Tomcat et occultent complètement la sécurisation du système et du réseau.

Il faut exécuter Tomcat avec un user qui dispose uniquement des privilèges requis pour l'exécution (par exemple, il ne faut surtout pas exécuter Tomcat avec le user root sous Unix mais créer un user tomcat dédié à son exécution).

Les utilisateurs possédant un rôle admin doivent avoir un mot de passe non trivial : il faut prohiber les user/mot de passe de type admin/admin.

Les droits d'accès aux répertoires et fichiers de Tomcat doivent être vérifiés pour ne pas permettre à quiconque de les modifier.

Il est préférable de ne pas installer l'outil d'administration : les fichiers de configuration doivent être modifiés à la main dans le système.

Il faut modifier les valeurs par défaut des attributs port et shutdown du tag <server> du fichier de configuration server.xml : ceci permet d'éviter un éventuel shutdown dû aux valeurs par défaut.

 

 


[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

78 commentaires Donner une note à l´article (5)

 

Copyright (C) 1999-2022 Jean-Michel DOUDOUX. Vous pouvez copier, redistribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU, Version 1.1 ou toute autre version ultérieure publiée par la Free Software Foundation; les Sections Invariantes étant constitués du chapitre Préambule, aucun Texte de Première de Couverture, et aucun Texte de Quatrième de Couverture. Une copie de la licence est incluse dans la section GNU FreeDocumentation Licence. La version la plus récente de cette licence est disponible à l'adresse : GNU Free Documentation Licence.