78. Maven 80. Des outils open source pour faciliter le développement Imprimer Sommaire Consulter avec table des matières
Développons en Java   v 1.90  
Copyright (C) 1999-2013 .  

 

79. Tomcat

 

chapitre 7 9

 

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 ces 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 :

Ce chapitre contient plusieurs sections :

 

 

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


Tomcat 3.x (version initiale)

Tomcat 4.x

Tomcat 5.x

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

 

79.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 sont 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 :

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

 

79.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 boite DOS, assigner le répertoire contenant Tomcat dans une 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.

 

79.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/

 

79.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 de fin d'affiche. Une case à cocher permet de demander le lancement de Tomcat. Cliquez sur le bouton « Finish »

 

79.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://tomcat.apache.org/download-55.cgi
Attention : Tomcat 5.5 est packagé différemment par rapport à 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 :

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 de Tomcat en s'assurant que celui-ci est arrêté.

 

79.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 http://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 via un assistant sur les pages :

 

79.2.6. La structure des répertoires

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

 

79.2.6.1. 1.2.6.1 La structure des répertoires de Tomcat 4

Le répertoire où est installé Tomcat est composé de l'arborescence suivante :

 

79.2.6.2. La structure des répertoires de Tomcat 5

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

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.

 

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

 

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

 

79.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/

 

79.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 commande (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 »

 

79.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 :

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

 

79.4. L'architecture

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

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

 

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

 

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

 

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

 

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

 

79.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 un 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 serveur 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 par rapport 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 :

Attribut

Rôle

docBase

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

 

 

reloadable

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

 

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

 

79.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 via 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

 

79.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 :

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éfini pour le user admin (information fournie 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 l'élément sélectionné. La liste déroulante « Actions » permet de réaliser des actions en fonction du contexte (création d'élément, 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.

 

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

 

79.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écessaire à 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>

 

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

 

79.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 :

 

79.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 du répertoire 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.

 

79.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 proposent 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.

 

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

 

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

 

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

 

79.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 le cycle de vie de l'application, 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.

 

79.8. Tomcat pour le développeur

 

79.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 com.jmdoudoux.mawebapp.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>com.jmdoudoux.mawebapp.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.

 

79.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 :

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

 

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

 

79.8.3.1. La configuration d'un contexte avec Tomcat 5

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

Les contexts 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 :

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

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 context est par exemple utilisée par Sysdeo dans son plug-in Eclipse pour faciliter l'utilisation de Tomcat.

 

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

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

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 com.jmdoudoux.test;

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 context de l'application.

 

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

 

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

Deux répertoires sont fournis à cet effet :

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 fournis 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 :

 

79.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 :

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

 

79.9.1. L'utilisation de l'interface graphique

Le manager de Tomcat est une application web exécutée dans Tomcat qui permet de gérer les applications exécutée 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 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 être utilisés pour 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 soit sur le poste client.

 

79.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 sur trouvant déjà sur la machine.

Il faut fournir trois données

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.

 

79.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 :

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 :

 

79.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é 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.

 

79.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 un point virgule : le contexte de l'application, son statut (running ou stopped), le nombre de sessions ouvertes et le chemin de la webapp

 

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

 

79.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 en 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

 

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

 

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

 

79.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 :

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

 

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

 

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

 

79.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 à démarrer. 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

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

 

79.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é. Il 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.

 

79.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 :

 

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

 

79.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 :

 

79.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 :

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 :

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 :

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 :

 

79.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 context : 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.

 

79.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 user possédant un rôle admin doivent avoir un mot de passe non triviale : 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 via 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.

 


  78. Maven 80. Des outils open source pour faciliter le développement Imprimer Sommaire Consulter avec table des matières Développons en Java   v 1.90  
Copyright (C) 1999-2013 .