|
|
|
|
|
|
Développons en Java v 1.60 | |
| Copyright (C) 1999-2011 Jean-Michel DOUDOUX |
 |
 |
 |
Ce chapitre contient plusieurs sections :
Tomcat est un conteneur d'applications web diffusé en open source sous une licence Apache. C'est aussi l'implémentation de référence des spécifications servlets et JSP implémentées dans les différentes versions de Tomcat.
En tant qu'implémentation de référence, 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 de plus en plus utilisé dans des environnements de production.
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'Eclipser 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 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 et même un JDK pour certaine ancienne version 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 :
Il est possible de récupérer tomcat sur le site de Jakarta. Il faut choisir la version stable de préférence et le répertoire bin pour récupérer le fichier jakarta-tomcat.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.
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 d'installation 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.29.exe sur le site http://jakarta.apache.org/site/binindex.cgi
Il faut télécharger le fichier jakarta-tomcat-5.0.16.exe sur le site http://jakarta.apache.org/site/binindex.cgi
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://tomcat.apache.org/download-55.cgi
Attention : Tomcat 5.5 est packagé différemment par rapport à ces 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écuter ce fichier.
Attention : l'installer 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 et 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é.
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 :
Le répertoire d'installation de Tomcat contient plusieurs répertoires.
Le répertoire où est installé Tomcat est composé de l'arborescence 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é 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 suffit 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 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é 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é en 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é 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 non distinct.
Le tag <Service> doit voir 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 mise à en attente si aucun thread n'est libre |
connectionTimeout |
timeout en milliseconde 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 |
activer 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) |
Une valve est une unité de traitements qui est utilisée lors du traitement de la requête. Leur rôle est similaire à celui des filtres pour les servlets.
Une est déclarée dans le fichier de configuration grâce au tag <valve> qui peut pet être utilisé comme fils des tags <engine>, <host> et <context>.
Une valve 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 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
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é de 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élection. La liste déroulante « Actions » permet 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 » : cet 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é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> |
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 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.
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 subie 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} ou {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 fourni l'application web Tomcat Manager pour permettre la gestion des applications web exécutée 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 des 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 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.
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.
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 hors 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 contexts peuvent être modifiés manuellement en modification 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 plugin Eclipse pour faciliter l'utilisation de Tomcat.
Tomcat propose une fonctionnalité particulière nommé « 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. Pour d'autres besoins que des tests, il ne faut pas utiliser cette fonctionnalité pour d'autres besoins et 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.
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 celle permet de rendre les applications moins dépendantes de Tomcat et chaque application pourrait utiliser une version différente de la bibliothèque.
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 utilisable par toutes les webapp qu'il exécute. Ces API sont dans le répertoire "common/lib" ou "shared/lib" de Tomcat :
Tomcat fourni une application web pour permettre la gestion des applications web exécutée sur le serveur sans avoir à procéder à un arrêt/redémarrage de Tomcat.
Cette application permet :
L'application Manager peut être utilisée de trois manières :
L'utilisation du manager est soumise à une authentification préalable avec un utilisateur possédant le rôle 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é au rôle 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. Il 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.
C'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.
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 à l'application Manager pour certaines machines en fonction de leur adresse IP ou de leur nom d'hôte
| 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.
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électionner 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 d'arrêter l'application en cliquant sur le lien « Arrêter » de l'application correspondante.
Il est possible de démarrer l'application en cliquant sur le lien « Démarrer » de l'application correspondante.
Il est possible de recharger l'application (équivalent à un arrêt/démarrage consécutif) en cliquant sur le lien « Recharger » de l'application correspondante.
Il est possible de supprimer l'application en cliquant sur le lien « Undeploy » de l'application correspondante.
L'application est arrêter et 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ésente la machine et le port utilisé par Tomcat. Commande est la commande à exécuter avec ces é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 elle-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.
Certaine commande renvoie des lignes supplémentaires contenant le résultat de la leur exécution.
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 session ouverte 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 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 |
La commandes resources permet d'obtenir une liste des ressources JNDI globales définie dans le serveur Tomcat et pouvant être utilisé.
| 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 le nom de la ressource et son type séparé 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 à 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 |
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 |
Remarque : cet exemple n'est utile que si l'option autoDeploy est à False dans la configuration du Host concerné.
| 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.
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 |
Liste des 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.
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, il possède 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.
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 occulte 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 grâce aux valeurs par défaut.
|
|
|
|
|
|
Développons en Java v 1.60 |
|
|
| Copyright (C) 1999-2011 Jean-Michel DOUDOUX |