| Développons en Java 2.30 | |
| Copyright (C) 1999-2022 Jean-Michel DOUDOUX | (date de publication : 15/06/2022) |
|
|
 |
 |
 |
|
| Niveau : |  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 :
Ce chapitre contient plusieurs sections :
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)
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
Tomcat 7.x
Tomcat 8.x
Tomcat 9.x
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 :
Sous Windows, Tomcat propose un package d'installation qui va permettre en plus :
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.
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/
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 ».
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 :
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é.
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 :
Le répertoire d'installation de Tomcat contient plusieurs répertoires.
L'arborescence du répertoire d'installation de Tomcat est la suivante :
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.
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.
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.
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/
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 »
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 :
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 :
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.
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.
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.
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.
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) |
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 |
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.
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é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.
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.
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> |
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.
Une application web peut être déployée sous Tomcat 5 de plusieurs manières :
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Un contexte peut être défini explicitement de plusieurs manières :
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 :
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 contexte est par exemple utilisée par Sysdeo dans son plug-in Eclipse pour faciliter l'utilisation de Tomcat.
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.
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.
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 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 :
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 :
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.
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 :
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.
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 :
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.
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.
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. |
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 |
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 |
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.
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 |
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 |
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 |
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.
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 |
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.
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 à leurs exécutions.
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 :
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 :
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.
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.
|
|
