Supportformationtomcat

APACHE TOMCAT
Mohamed Iheb Eljani

iheb.eljani@gmail.com
1
Plan
 Introduction  Déploiement
d’application
 Installation
 Cluster
 Configuration
 Class Loader  Instances Multiples
 Journalisation  APR
 Sécurité
 JMX Monitoring
03/04/2014 2
Introduction
Moteur JSP/Servlet
 Servlet est une classe Java qui permet de générer

dynamiquement du contenu (HTML, XML, TEXT, …) au
sein d'un serveur HTTP dit conteneur de servlets.
 Les servlets utilisent l'API Java Servlet (javax.servlet).
 L’API Servlet fournit un mécanisme pour communiquer avec
le serveur et de réagir aux requêtes HTTP.
 JavaServer Pages ou JSP est une technologie Java qui

permet de créer dynamiquement du contenu web en
ajoutant de la logique dynamique (tags JSP, scriplet JAVA)
au sein d’un contenu statique.
 Lors de la 1er utilisation de la page JSP, elle transformé en
servlet.
 Un conteneur de servlet est une plateforme qui fournit un

environnement JAVA pour gérer le cycle de vie d’une
servlet
Introduction
Moteur JSP/Servlet
Introduction
Historique
 Apache TOMCAT est le conteneur de servlet fourni par la

communauté open source Apache Foundation Software.
 TOMCAT est le produit de la fusion du projet Java Web

Server de Sun et du projet JServ de la communauté
Apache.
 La 1er version produite est la version 3, en 1999.
 En 2001, la version 4 est sorti sous le nom de code

Catalina et qui représentait une refonte total du produit.
 Catalina : Le noyau de TOMCAT, Servlet API, Administration,
Sécurité, …
 Coyote : Le connecteur HTTP qui permet à TOMCAT de servir
comme serveur HTTP
 Jasper : Le compilateur qui traduit la JSP en Servlet
Introduction
Versions
 Versions en cours
 8.0.x : en mode maintenance, pas de nouveaux
développement
 9.0.x : version actuelle
 Disponible sur le site http://tomcat.apache.org/

Introduction
Versions
Version
Version Tomcat Version Servlet Version Java
JSP
7.0 3.0 2.2 1.6
8.0 3.1 2.3 1.7
9.0 4.0 2.3 1.8

Installation
 Apache TOMCAT peut être téléchargé à partir d’un
des liens suivants :
 http://tomcat.apache.org/download-70.cgi
Installation
 Le site propose plusieurs types de ressources :
 Core :
 Des archives zip ou tar, décompressés fournissent
un dossier qui constitue le serveur TOMCAT
 Des exécutables d’installation pour la plateforme
Windows
 Deployer : Module ANT pour automatiser le

déploiement d’application
 Embedded : Ensemble de composants nécessaire pour

créer des application WEB avec un TOMCAT Embedded
Installation
Pré requis
 TOMCAT est une application JAVA et nécessite donc

la disponibilité d’un JDK dans la machine cible.
 TOMCAT nécessite la disponibilité non pas d’un simple
JRE, mais de l’ensemble du JDK. Il a besoin du
compilateur javac pour compiler les servlets
résultantes des JSP.
 La version 9.0 nécessite un JDK 1.8 et supérieure
 La variable d’environnement JAVA_HOME doit pointer

sur le dossier racine du JDK
 La valeur JAVA_HOME/bin doit exister au niveau de la

variable d’environnement PATH
Installation
Windows
 En utilisant l’archive téléchargé

 Déployer l’archive dans un dossier cible
 Ajouter la variable d’environnement CATALINA_HOME
qui pointe sur le dossier d’installation de TOMCAT
 Utiliser l’exécutable d’installation

 Plus simple
 Se charge de la configuration des variables
d’environnement
 Installe TOMCAT en tant que service Windows
Installation
Unix
 Déployer l’archive téléchargé dans un dossier cible

 Ajouter la variable d’environnement
CATALINA_HOME qui pointe sur le dossier
d’installation de TOMCAT
 Pour éviter des problèmes de stabilité sur les
plateformes linux :
 Linux kernel 2.4 et GLIBC 2.2 : définir la variable
d’environnement LD_ASSUME_KERNEL=2.2.5
 Redhat Linux 9.0 : définir la variable d’environnement
LD_ASSUME_KERNEL=2.4.1
uname -r : identifier la version du kernel linux

/lib/libc.so.6 : identifier la version du GLIBC
Installation
Unix
 La plupart des distributions Linux modernes offre un

package tomcat prêt pour installation :
 Debian et Ubuntu :
 Installation : apt-get install tomcat9
 CentOS, Fedora, Red Hat :

 Installation : yum install tomcat9
Installation
Démarrage
 Le démarrage de TOMCAT :
 Windows : %CATALINA_HOME%/bin/startup.bat
 Linux : $CATALINA_HOME/bin/startup.sh
Installation
Structure
 conf : Fichiers de configuration
 catalina.policy : les paramètres de sécurité JAVA appliqués en
remplacement du paramétrage java.policy
 catalina.properties : Définition des différents classLoader
 context.xml : indique l’emplacement par défaut du fichier
web.xml au niveau des application WEB
 logging.properties : configuration par défaut de la
journalisation TOMCAT
 server.xml : Fichier de configuration principale de TOMCAT
 tomcat-users.xml : fichiers de configuration des droits d’accés
aux applications d’administration
 web.xml : web.xml par défaut utilisé par toutes les
applications déployés
 Identifie la servlet pour récupérer les documents statiques
 Identifie la servlet responsable de la transformation de la JSP en
servlet
 Identifie le timeout session
 Installe les mime types pour les extensions standards
Installation
Structure
 bin : scripts et exécutables pour différentes tâches :

démarrage, arrêt, etc.
 lib : l’ensemble des jars utilisés
 logs : journaux
 temp : répertoire utilisé pour des fichiers temporaires,

fichier de crash, fichier en cours d’upload, …
 work : répertoire utilisé lors de transformation des JSP en

servlet
 webapps : répertoire de déploiement des applications

WEB
Installation
Structure
 Le répertoire webapps par défaut contient les

applications suivantes :
 ROOT : application par défaut
 docs : documentation tomcat
 examples : des exemples de JSP et de servlet
 host-manager : application qui permet de gérer le
serveur hôte. Accessible à partir de l’url /host-
manager/html
 manager : application qui permet de gérer le cycle de
vie des applications WEB déployés au sein du serveur.
Accessible à partir de l’url /manager/html
Configuration
Concepts
Configuration
Concepts
 Server : encapsule le conteneur web. Il ne peut

s'exécuter qu'un seul Server dans une JVM
 Connector : gère et intercepte les communications

avec le client.
 http Connector : responsable de gérer les appels HTTP
 AJP Connector : plus performant que le connecteur
HTTP et permet de faire communiquer TOMCAT avec
un serveur Apache HTTP dans une architecture reverse
proxy.
 Engine : composant responsable de traiter les

requêtes HTTP, il examine l’entête HTTP de la
requête pour identifier le hôte virtuel et le tomcat
(application) responsable de traiter la requête.
Configuration
Concepts
 Service : composant logique qui associe un

connecteur ou plus avec l’Engine responsable de
traiter les requêtes reçues.
 Host : concept qui ressemble à son équivalent hôte

virtuel coté apache, permet de configurer plusieurs
nom de domaine dans une même machine.
 Context : représente l’application WEB déployé et

permet l'association de cette application à une url.
Configuration
Concepts
 Valve : Composant capable d’implémenter un

traitement qui est exécuté avant la prise en compte
de la requête par l’Engine responsable.
 org.apache.catalina.valves.ValveBase
 Realm : Une source de données qui fournit une liste

d’utilisateurs et leurs rôles associés. Permet de
définir les droits d’accès pour les applications WEB
Configuration
Server.xml
 Le fichier Server.xml représente le point central pour la

configuration du serveur TOMCAT
 Le fichier ou est configuré l’ensemble des composants

TOMCAT
 Server, Service, Connector, Host, Engine, …
 Server.xml, comme son nom l’indique est un fichier XML,

et comme tout document XML il a une balise racine,
<Server>, elle représente le serveur.
 port : port TCP sur lequel écoute TOMCAT pour la commande
d’arrêt.
 shutdown : chaîne texte qui représente la commande d’arrêt
Configuration
Server.xml : <Server>
Configuration
Server.xml : <Server>
 <Listener> : Listener pour intercepter les

événements du cycle de vie du serveur (démarrage,
arrêt, avant démarrage, avant arrêt, …)
 className : nom de la classe du listener et qui
doit implémenté l’interface
org.apache.catalina.LifecycleListener
 <GlobalNamingResources> : ressources JNDI

accessible de façon global au niveau du serveur
Configuration
Server.xml : <Service>
 <Service> : regroupe un ou plusieurs connecteurs

et un Engine responsable de traiter les requêtes
interceptés par ces connecteurs
 <Connector> : un ou plusieurs, responsable de
l’interception de requêtes HTTP.
 <Engine> : composant responsable du traitement des

requêtes interceptés par les connecteurs du même
service.
Configuration
Server.xml : <Connector>
 port : port TCP sur lequel écoute le connecteur, c’est le port

associé à l’hôte définie au sein du service et c’est lui qui devra
être ciblé par les requêtes clientes
 Protocol : type du connecteur, 2 valeurs possibles

 HTTP/1.1 : à utiliser si le connecteur est ciblé par des requêtes HTTP
et que TOMCAT joue le rôle d’un serveur HTTP
 AJP/1.3 : à utiliser TOMCAT joue le rôle d’un serveur d’application
dernier une passerelle HTTP
 maxThreads : nombre max de threads crées simultanément pour

traiter les requêtes reçus, identifie le nombre de requêtes traités
en parallèles.
 200 si vide
 connectionTimeOut : temps d’attente de la requête pour être

traité
 redirectPort : le port sur lequel doit être redirigé les requêtes

avec SSL si le connecteur ne supporte pas SSL
Configuration
Server.xml : <Engine>
 defaultHost : hôte par défaut, utilisé si plusieurs hôtes

sont déclarés et que le hôte cible de la requête traité n’est
pas identifié
 <Host> : un ou plusieurs, identifie un hôte virtuel

 <Context> : ensemble de paramétrage pour configurer
une application WEB
 <Realm> : configure les droits d’accès au niveau de
l’Engine
 <Valve> : logique de pré traitement de la requête reçu
avant son interception par l’application cible
 <Listener> : Listener pour intercepter les événements de
cycle de vie de l’Engine (démarrage et arrêt)
Configuration
Server.xml : <Host>
 name : le nom utilisé par le hôte virtuel

 Doit être disponible au niveau du DNS et qui doit
pointer sur l’adresse IP de la machine.
 appBase : répertoire contenant les applications à
déployé, part défaut c’est CATALINA_HOME/webapp
 Si le chemin commence par un « / », il pointe sur un
chemin absolu, sinon il pointe sur un sous répertoire
du CATALINA_HOME
 autoDeploy : si Oui, les applications disponible dans
le répertoire appBase seront déployé
automatiquement et si le source d’une application
est changé elle sera redéployé
Configuration
Server.xml : <Host>
 deployOnStartup : si Oui, les applications disponible

dans le répertoire appBase seront déployé
automatiquement au démarrage.
 deployXML : si Oui, le processus de déploiement se
basera sur le fichier /META-INF/context.xml au sein
de l’application pour configurer le tomcat de
l’application, si Non une balise <context> devra être
ajouté directement dans le fichier Server.xml
 unpackWARs : si Non, l’application sera déployé
sans désarchiver le ficher WAR, par défaut c’est Oui
 workdir : répertoire temporaire pour transformer les
JSP en Servlet, par défaut c’est
CATALINA_HOME/workdir
Configuration
Server.xml : <Host>
 <Alias> : permet d’associer ce hôte à d’autres nom

au sein du DNS, autre que le nom de l’hôte
 <Context> : un ou plusieurs, ensemble de

paramétrages pour configurer une application WEB
 <DefaultContext> : ensemble de paramétrage

utilisé par défaut par les applications n’ayant pas de
tomcat propre identifié
 <Realm> : configure les droits d’accès au niveau de

l’Hôte
Configuration
Server.xml : <Context>
 docBase : le répertoire ou sont stockés les

fichiers de l’application
 Si l’application est déployé avec un WAR, le
répértoire est webapps/nom_fichier_war
 path : le chemin de tomcat à utiliser dans

l’URL pour invoquer à l’application
 Utiliser chaîne vide pour que ce soit l’application
par défaut du hôte, « / » sera le tomcat de
l’application
 Par défaut c’est le non fourni par docBase
Configuration
 cookies : si Oui, utiliser les cookies pour gérer la

session, par défaut c’est oui
 useNaming : indique que l’application effectue des

accès à des ressources JNDI
 crossContext : si Oui, permet d’accéder à des

informations dans d’autres tomcats du même hôte,
par défaut c’est Non
 override : si Oui, indique que la configuration

proposé par le fichier META-INF/context.xml de
l’application écrase celle définie au niveau du fichier
server.xml
Configuration
 caseSensitive : indique si la prise de la case est

active, par défaut c’est Oui
 reloadable : si Oui, indique que si un fichier de

l’application change, redéployer l’application
automatiquement, permet d’écraser le paramétre
autoDeploy du hôte
 unpackWAR : si Non, l’application sera déployé sans

désarchiver le ficher WAR, par défaut c’est Oui
Configuration
 cachingAllowed : si Oui, avtive la mise en cache des

ressources statiques
 cacheMaxSize : taille maximum en KO du cache, par

défaut 10240.
 cacheTTL : temps de latence d’un objet dans le

cache, par défaut 5000 ms
Configuration
 <Loader> : Configuration du classLoader à utiliser

pour les classes de l’application
 <Manager> : gestionnaire de session à utiliser
 Ne pas changer sauf en cas de mise en place de
session persistante (application transactionnel,
cluster, …)
 <Realm> : gestion d’accés au niveau de l’application
 <Resources> : le gestionnaire de resource à utiliser
pour les ressources JNDI
 org.apache.naming.resources.FileDirContext
 <WatchedResource> : redéployer l’application si
une des ressources spécifiés change
Configuration
Context.xml
 Le fichier Context.xml permet de fournir un

paramétrage par défaut pour l’ensemble des
applications déployés au sein de TOMCAT
 La balise racine est <Context>

Configuration
web.xml
 Le fichier web.xml permet de configurer des

paramètres par défaut pour l’ensemble des
applications déployés dans TOMCAT
 Comme tout fichier de déploiement web.xml, la

balise racine est <web-app>
Configuration
web.xml : Servlet par défaut
 Configurer la Servlet par défaut responsable de

gérer les ressources statiques au sein des
applications déployés
Configuration
web.xml : Servlet par défaut
 listings : indique si le contenu du dossier est affiché

si l’url se termine par « / », par défaut c’est Non
 readonly : indique si les méthodes post et put sont

permis pour accéder à des sources statiques, par
défaut c’est Oui
 sendfileSize : permet de gérer la taille du tampon

avant appel d’un sendFile() lors du traitement d’un
contenu volumineux, par défaut c’est 48ko
Configuration
web.xml : Configurer JSPServlet
 La JSPServlet est le composant responsable

d’intercepter les requêtes .jsp et de les traiter.
 Elle prend en charge la conversion des jsp en servlet
et leurs compilation
Configuration
 developement : indique à Jasper de surveiller les jsp

et si une modification est détecté de la recompilé,
par défaut Oui
 checkInterval : intervalle de vérification du

changement des JSP, par défaut 0
 modificatioTestInterval : indique le délai de latence

après une recompilation pour revérifier la JSP, 4s
par défaut
Configuration
 fork : indique d’utiliser une autre JVM pour compiler

la JSP autre que la JVM par défaut. Oui par défaut
 compilerTargetVM : version java cible de la

compilation, par défaut garde la version de la JVM
TOMCAT
 compilerSourceVM : version java à utilisé pour

générer le code source de la Servlet généré, par
défaut garde la version de la JVM TOMCAT
Configuration
web.xml : Session Timeout
 Spécifier la durée d’inactivité d’une session HTTP,

après laquelle la session est désactivé.
 La valeur est en minute

Configuration
web.xml : Les fichiers d’accueil
 Liste des fichiers d’accueil que la Servlet par défaut

essaie d’afficher si elle reçoit une requête qui se
termine par un /
 Cette liste peut être surchargé par le web.xml de

l’application déployé
ClassLoader
 TOMCAT utilise plusieurs ClassLoader pour charger
les classes utilisés au sein de la JVM
 Chaque ClassLoader (java.lang.classLoader) est

responsable du chargement des classe et des
ressources d’un contenu spécifique
 Ce mécanisme permet aux applications, déployés au

sein de TOMCAT, de pouvoir utiliser l’ensemble des
classes fournies.
ClassLoader
 Comme dans toute application JAVA, les classLoader
au sein de TOMCAT sont organisés en arbre
 Ce mécanisme permet de réaliser une isolation entre

les class path des différents application
ClassLoader
 Bootstrap : contient les classes de base de la JDK.
 System : contient les classes qui gére le cycle de vie du serveur

TOMCAT
 $CATALINA_HOME/bin/bootstrap.jar
 $CATALINA_HOME/bin/tomcat-juli.jar
 $CATALINA_HOME/bin/commons-daemon.jar
 Common : contient les autres classes fournies par TOMCAT

 $CATALINA_HOME/lib
 WebappX : un ClassLoader est crée pour chaque application web

déployé au sein de TOMCAT
 /WEB-INF/classes
 /WEB-INF/lib
ClassLoader
Endorsed Standards Override Mechanism
 Endorsed Standards Override Mechanism est un mécanisme

JAVA qui permet aux applications de fournir une
implémentation de certaines API JAVA autre que
l’implémentation fourni par le JDK.
 org.xml.sax
 org.xml.sax.ext
 org.xml.sax.helpers
 TOMCAT permet d’implémenter ce mécanisme par le biais du

paramètre -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
au niveau de la commande de démarrage.
 $JAVA_ENDORSED_DIRS : par défaut est $CATALINA_HOME/endorsed
ClassLoader
catalina.policy
 Fichier utilisé par le gestionnaire de sécurité JAVA

pour identifier les permissions autorisés pour les
accès aux ressources systèmes par TOMCAT
 respecte le format JAVA pour spécifier les permissions
 n’est utilisé que si TOMCAT est démarré en mode
sécurisé.
$CATALINA_HOME/bin/startup.sh –security
 Remplace complètement le fichier standard JAVA

java.policy présent dans le JDK
 Il peut être édité manuellement ou via l’outil

policytool offert par le JDK
ClassLoader
catalina.policy
 La tentative d’exécution par TOMCAT d’une

opération non autorisé par le gestionnaire de
sécurité JAVA, déclenche une violation qui peut
générer deux types d’exceptions
 java.security.AccessControLException
 java.security.SecurityException
 Le débogage de ce type de problème peut parfois

être assez complexe, TOMCAT offre la possibilité de
générer des informations de débogage
supplémentaires lors de la violation
 export CATALINA_OPTS=-Djava.security.debug=all
(Unix)
 set CATALINA_OPTS=-Djava.security.debug=all
(Windows)
JNDI Ressources
 JNDI pour Java Naming and Directory Interface
 JNDI est une interface Java unique pour accéder à

des services distribués et des données en leurs
associant un nom unique, et définit une API
standard pour permettre l'accès à ces services.
 Il existe plusieurs types de services de nommage

parmi lesquels :
 DNS (Domain Name System)
 LDAP(Lightweight Directory Access Protocol)
 NIS (Network Information System)
 COS Naming (Common Object Services)
 Etc …
JNDI Ressources
 TOMCAT fournit une prise en charge du JNDI
compatible JEE
 TOMCAT fournit une instance du JNDI InitialContext

pour chaque application web déployé, et permet de
définir et d’exploiter des ressource JNDI en utilisant
les balises standard JEE au niveau des fichier
web.xml, context.xml et server.xml.
JNDI Ressources
Configuration
 L’identification et la configuration d’une ressource

JNDI se fait au sein de la balise <Context> dans l’un
des fichiers suivants :
 server.xml : au sein d’une balise <Context>
 context.xml : propre à chaque application
déployé.
 <Environment> : permet de configurer des

variables d’environnement dont la valeur peut être
exploité par l’application WEB grâce au JNDI
Context.
 <Resource> : permet de configurer une ressource

JNDI
JNDI Ressources
Configuration : <Environnement>
 name : nom de la variable
 description : description textuelle de la variable
 override : booléen, indique si cette variable peut être redéfinie au

sein du fichier web.xml via la balise <env-entry>
 type : classe java qui représente le type de variable
 value : la valeur de la variable
<Environment name="simpleValue" type="java.lang.Integer" value="30"/>
Context initCtx = new InitialContext();

Context ctx = (Context)
initCtx.lookup("java:/comp/env");
Integer o = (Integer) ctx.lookup("simpleValue");
JNDI Ressources
Configuration : <Resource>
 auth : application / container, indique qui est responsable

de la gestion du cycle de vie de la ressource.
 type : classe java qui représente le type de la ressource
 singleton : booléen, indique si TOMCAT gère la ressource
en tant que singleton
 closeMethod : méthode à utiliser par TOMCAT pour libérer
la ressource quand elle n’est plus utilisé.
 Ce paramètre est ignoré si singleton est true.
 description : description textuelle de la ressource
 name : nom de la ressource
 scope : Shareable / Unshareable, indique si les
connections obtenues via la ressource peuvent être
partagé
JNDI Ressources
Configuration : <Resource>
 La balise <Resource> peut accepter d’autres

attributs que les attributs déjà vu, ils seront utilisé
par le JNDI Context lors de la création de la
ressource
<Resource name="jdbc/TestDataSource" auth="Container"

type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
maxActive="100" maxIdle="30" maxWait="10000"
url="jdbc:mysql://localhost:3306/test_db"
username="root" password="root" />
JNDI Ressources
Ressource Global
 La balise <GlobalNamingResources> permet

d’identifier des ressources JNDI globaux et qui sont
accessibles par l’ensemble des applications déployés
au sein du serveur
 La balise <GlobalNamingResources> englobe des

balises <Resource> et <Environnement> comme
sous éléments qui configurent des ressources JNDI
 Les ressource configurés de façon globales sont

réutilisés au sein d’une application par l’utilisation de
la balise <ResourceLink> au sein du tomcat de
l’application.
JNDI Ressources
Ressource Global : <ResourceLink>
 name : nom de la ressource à utilisé par l’application pour

accéder à la ressource
 type : classe java qui représente le type de la ressource
 global : nom de la ressource globale identifié
<GlobalNamingResources>
<Environment name="serverType" type="java.lang.String"
value="DEV"/>
</GlobalNamingResources>
<Context>
<ResourceLink name="serverType" global="serverType"
type="java.lang.String"/>
</Context>
JNDI Ressources
Utilisation
 L’utilisation d’une ressource JNDI au sein d’une

application nécessite l’identification de la ressource
au sein du web.xml
 <env-entry> : permet de référencer une variable

d’environnement <Environnement>.
<env-entry>
<env-entry-name>MaxValue<env-entry-name>
<env-entry-type>java.lang.Float</env-entry-type>
<env-entry-value>45.4</env-entry-value>
</env-entry>
 <resource-ref> et <resource-env-ref> : permet de

référencer une ressource JNDI.
JNDI Ressources
Utilisation
JNDI Ressources
Resource Factory
 Lors de la récupération de la ressource, le JNDI Context a

besoin de savoir comment initialiser cette ressource.
 L’interface javax.naming.spi.ObjectFactory fournit par

JAVA permet de concevoir des fabriques que le JNDI
Context va utiliser lors de l’opération de récupération.
 Fournit la méthode getObjectInstance() qui est appelé lors

de l’initialisation de la ressource
 Object obj : objet of type javax.naming.Reference, contient
les informations de configuration de la ressource
 Name name : nom de la factory.
 Context nameCtx : Context JNDI en cours
 Hashtable environment : généralement ignoré par TOMCAT.
JNDI Ressources
Resource Factory
JNDI Ressources
JDBC Datasources
<Context>
...
<Resource name="jdbc/EmployeeDB" auth="Container"
type="javax.sql.DataSource"
username="dbusername" password="dbpassword"
driverClassName="org.hsql.jdbcDriver"
url="jdbc:HypersonicSQL:database" maxActive="8" maxIdle="4"
defaultAutoCommit ="false" defaultTransactionIsolation =
"READ_COMMITTED" initialSize="5"
/>
...
</Context>
<resource-ref>
<res-ref-name> jdbc/EmployeeDB </res-ref-name>
<res-type> javax.sql.DataSource </res-type>
<res-auth> Container </res-auth>
</resource-ref>
JNDI Ressources
JAVA Mail Sessions
Journalisation
 La journalisation au sein de TOMCAT est implémenté
grâce à l’API Apache Commons Logging.
 Cette API permet à TOMCAT d’être indépendant du

framework de journalisation utilisé et de pouvoir
utilisé n’importe lequel du marché
 Chaque application déployé au sein de TOMCAT peut

utilisé son propre framework de journalisation
indépendamment de ce que utilise TOMCAT
 Sauf pour le framework utilisé par TOMCAT.
Journalisation
logging.properties
 Le fichier logging.properties est organisé en deux

sections
1. Les gestionnaires (handlers) : ils permettent de
spécifier la configuration du journal, destination,
niveau de détail, chemin du fichier journal, …
 vers un fichier : org.apache.juli.FileHandler
 Vers la console : java.util.logging.ConsoleHandler
2. Les loggers : ils identifient le contenu à journaliser et

le niveau de détail du journal pour ce contenu
Journalisation
logging.properties
 La propriété handlers identifie tous les gestionnaires

de journaux utilisés.
 La propriété .handlers identifie le gestionnaire

principale du serveur
 Le nom du handler est constitué de deux parties

1. un préfixe construit à partir d’un chiffre et d’un nom,
exemple : 1catalina
2. le nom de la classe du gestionnaire
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory =
${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
Journalisation
logging.properties
 level : niveau de journalisation.

 SEVERE, CONFIG, INFO, WARN, FINE, FINEST, ALL
 formatter : classe java pour formater le contenu du

fichier.
 java.util.logging.SimpleFormater (par défaut)
 java.util.logging.XmlFormater pour générer sortie
format XML
 Les attributs spécifiques à org.apache.juli.FileHandler

sont :
 prefix : spécifie le préfixe du fichier. La valeur par défaut
est ’juli.’
 suffix : spécifie le suffixe du fichier. La valeur par défaut
est ’.log’
 directory : spécifie répertoire dans lequel sera créé le
fichier. Par défaut TOMCAT_HOME\bin\logs
Journalisation
logging.properties
 Pour spécifier le contenu d’un journal il faut

respecter l’une des syntaxes suivantes
 org.apache.catalina.core.ContainerBase.[engine]
 org.apache.catalina.core.ContainerBase.[engine].[host]
 org.apache.catalina.core.ContainerBase.[engine].[host].[context]
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handl
ers = 3manager.org.apache.juli.FileHandler
 Il est aussi possible de spécifier le nom d’une classe

comme contenu d’un journal
 la rotation des fichiers journaux s’effectue toutes les

nuits à minuit
Journalisation
Journalisation des accès
 En tant que serveur HTTP TOMCAT fournit un autre

mécanisme pour suivre les statistiques des accés aux
ressources publiés que ce soit des ressources statiques ou
dynamiques (JSP)
 La valve AccessLog crée des fichiers journaux dans le

même format que ceux créés par les serveurs Web
standard. Ces journaux peuvent ensuite être analysés par
des outils d'analyse de log pour suivre les statistiques
d’accés, l'activité de la session de l'utilisateur, et ainsi de
suite.
 La valve AccessLog peut être associé à n'importe quel

conteneur TOMCAT (tomcat, hôte, Engine), et enregistre
toutes les demandes traitées par ce conteneur
Journalisation
Journalisation des accès
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="localhost_access_log. "
suffix=".log"
pattern="%h %l %u %t "%r" %s %b" />
 Si la valve AccessLog est utilisé à des endroits

différents, il faut faire attention à utiliser des fichiers
de journal différents
Journalisation
en Production
 Ne pas utiliser de ConsoleHandler.
 Nettoyer le propriété .handlers et ne garder que le

FileHandler
 Supprimer les handlers et les journaux des applications

non utilisés
 Faite attention lors de l’utilisation de la valve Access log.
 Configurer les journaux vers un disque autre que celui de

TOMCAT
Journalisation
Atelier
 Configurer des journaux pour les hosts crées dans

l’atelier 1
 Configurer un journal pour l’application « example »
 Configurer un journal d’accès pour l’application

«example »
 Configurer un journal d’accès pour le 2éme hôte

Sécurité
 TOMCAT offre un mécanisme de gestion
d’authentification et de contrôle d’accès, ce
mécanisme offre les garanties suivantes :
 Authentification : garantir que l’utilisateur connecté est

bien celui qu’il prétend.
 Autorisation : définir pour chaque utilisateur le

périmètre auquel il peut accéder.
 Protection des données : garantir que les données en

circulation ne sont pas altérés par une tierce partie.
Sécurité
Authentification
 L’authentification au sein de TOMCAT et comme dans

beaucoup de moteur de Servlet, peut être implémenté de
deux façons
 HTTP basic authentication : c’est le navigateur WEB qui se charge

de réclamer le nom d’utilisateur et le mot de passe à l’utilisateur
et puis de les envoyer au serveur pour être validé.
 Form-based authentication : c’est l’application qui fournit un
formulaire web pour réclamer le nom d’utilisateur et le mot de
passe
 Il est important de noter qu’en mode HTTP basic

authentication le mot de passe et le nom d’utilisateur est
envoyé crypté alors qu’en mode Form-based authentication
ils sont envoyés en clair et dans ce cas il est necessaire de
passer par du SSL
Sécurité
Identification des utilisateurs : <Realm>
 Un <Realm> est un dispositif servant à identifier des

utilisateurs et leurs rôles.
 Il permet de faire l'association login/mot de passe

de l’utilisateur
 le <Realm> identifie la liste des rôles associés à

chaque utilisateur. Les rôles sont les responsabilités
attribuées à un utilisateur donné.
 La protection des ressources se fait par rôle, c'est-à-
dire que l'on indique le rôle dont doit disposer un
utilisateur pour accéder à la ressource.
Sécurité
 Un <Realm> peut exploiter des données stockées

sous différentes formes :
 annuaire LDAP accessible via JNDI,
 fichier XML (par exemple le fichier tomcat-
users.xml qui sert à configurer l'accès aux
applications admin et manager de Tomcat)
 une DataSource JNDI
 …
 L'interface org.apache.catalina.Realm permet

d’implémenter un <Realm> propriétaire
Sécurité
 Un <Realm> peut se déclarer en plusieurs niveaux
 Engine : partagé par toutes les applications de tous les

hôtes virtuels
 Host : (partagé par toutes les applications de l'hôte

virtuel)
 Context : valable pour l'application dans lequel il est

défini.
 Un <Realm> défini à un niveau donné masque ceux

de niveau supérieur.
Sécurité
 JDBCRealm : permet d’accéder à des informations

utilisateurs stockés au niveau d’une BD via JDBC
<Realm
className="org.apache.catalina.realm.JDBCRealm"
driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/authority?us
er=dbuser&password=dbpass"
userTable="users" userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles"
roleNameCol="role_name"/>
Sécurité
 DataSourceRealm : permet d’accéder à des

informations utilisateurs stockés au niveau d’une BD
via une datasource JNDI
<Realm
className="org.apache.catalina.realm.DataSourceR
ealm" dataSourceName="jdbc/authority"
userTable="users" userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles"
roleNameCol="role_name"/>
Sécurité
 UserDatabaseRealm : permet d’accéder à des

informations utilisateurs stockés au niveau d’une
ressource JNDI UserDatabase.
<Resource name="UserDatabase" auth="Container"

type="org.apache.catalina.UserDatabase"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory
« pathname="conf/tomcat-users.xml" />
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
Sécurité
 JNDIRealm : permet d’accéder à des informations

utilisateurs stockés au niveau d’un annuaire LDAP
via une ressource JNDI.
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionName="cn=Manager,dc=mycompany,dc=com"
connectionPassword="secret"
connectionURL="ldap://localhost:389"
userPassword="userPassword"
userPattern="uid={0},ou=people,dc=mycompany,dc=co
m" roleBase="ou=groups,dc=mycompany,dc=com"
roleName="cn" roleSearch="(uniqueMember={0})" />
Sécurité
 JAASRealm : permet d’accéder à des informations

utilisateurs via le framework Java Authentication &
Authorization Service (JAAS)
<Realm
className="org.apache.catalina.realm.JAASRealm"
appName="MyFooRealm"
userClassNames="org.foobar.realm.FooUser"
roleClassNames="org.foobar.realm.FooRole"/>
Sécurité
 LockOutRealm : permet de mettre en place un

mécanisme de protection contre les tentatives
brute-force attack pour accéder au systéme de façon
illégale, il est utilisé en combinaison avec d’autres
Realm
<Realm className="org.apache.catalina.realm.LockOutRealm"
failureCount="3" lockOutTime="300" >
<Realm
className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
Sécurité
 CombinedRealm : permet de combiner plusieurs sources

d’utilisateurs en un seul Realm
<Realm className="org.apache.catalina.realm.CombinedRealm" >

<Realm
className="org.apache.catalina.realm.UserDatabaseRealm
" resourceName="UserDatabase"/>
<Realm
className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/authority" userTable="users"
userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name"/>
</Realm>
Sécurité
Mode d’Authentification
 La balise <Login-config> au niveau du web.xml,

permet de spécifier le mode d’authentification de
l’application
 <auth-methode> : None / Basic / Form /DIGEST

/ CLIENT-CERT, identifie le mode
d’authentification de l’utilisateur
 <realm_name> : le Message d’invite utilisé par

l’application.
Sécurité
Mise en place du formulaire d’authentification
 Créer un formulaire HTML

 Le champ correspondant au login doit s'appeler
j_username;
 Le champ du mot de passe doit s'appeler j_password;
 L'action du formulaire doit être j_security_check.
 Créer une page d’erreur pour répondre au cas ou

l’authentification ne s’est pas bien passé
Sécurité
Autorisation
 Les autorisations sont définies pour une application

au sein du fichier web.xml par la balise <security-
constraint>.
 <security-constraint> : permet de définir des

droits d’accés sur un ensemble de ressource en
utilisant le principe du mapping d’URL :
 <web-resource-collection> : liste de pattern d’URL qui
identifinet les ressources à protéger
 <auth-constraint> : identifie qui a droit d’accès à ces
ressource via le sous élément <role-name>.
 <user-data-constraint> : spécifie si les données sont
cryptés lors du transfert des données entre le serveur
et le client
Sécurité
Autorisation
 <web-resource-collection> contient les

sous éléments suivant :
 <web-resource-name> : (optionel) un nom.
 <url-pattern> : le pattern URL des ressources à
protéger.
 <http-method> : (optionnel) spécifie quelle
méthode HTTP est protégé.
 <auth-constraint> : contient le sous

élément suivant :
 <role-name> : (plusieurs) rôle qui a accès à la
ressource.
Sécurité
Autorisation
Sécurité
Single Sign On
 TOMCAT offre un mécanisme qui permet à plusieurs applications

d’un Host de partager l’authentification
<Host name="localhost" ...>

...
<Valve
className="org.apache.catalina.authenticator.SingleSignOn"/>
...
</Host>
 L’utilisation de ce mécanisme nécessite quelques règles :

 Les applications partagent le même Realm
 Si une des application ne nécessite pas d’authentification,
l’utilisateur n’accède qu’aux ressources non protégés des autres
applications
 Single Sign On utilise les cookies pour partager les informations
d’authentifications entre les applications.
Sécurité
SSL
 La balise <Connector> est la responsable de

l’activation et de la prise en charge du SSL au
niveau de TOMCAT
 SSLEnabled : true, active la prise en compte du SSL
 Secure : true, active la prise en compte du HTTPS
 sslProtocole : indique le protocole SSL à utilisé
 keystoreFile : indique l’emplacement du fichier de
certificats
 Keystoretype : indqiue le type de clés contenues dans
le fichier de certificats
 keystorePass : le mot de passe nécessaire à TOMCAT
pour pouvoir lire le fichier de certificat
 clientAuth : indqiue si le serveur authentifie le client
grace à un certificat client hébergé par le client
Sécurité
SSL
 La balise <user-data-constraint> au niveau du

web.xml permet d’indiquer que les donnés
transférés par cette application doivent être cryptés
Sécurité
Atelier
 Activer la sécurité au niveau d l’application «

example » en utilisant le Realm UserDataSource
 Ne permettre l’accés à «/examples/servlets/ » qu’au

nouveau rôle « servlet »
 Activer le SSO au niveau de votre Host

Déploiement d’application
Application standard
 TOMCAT propose plusieurs façons pour déployer des

applications. En plus du déploiement lors du
démarrage, il propose plusieurs possibilités de
déploiement à chaud.
 Le déploiement à chaud permet d’ajouter des

applications, de les mettre à jour ou de les retirer
sans avoir besoin d’effectuer un redémarrage de
TOMCAT.
Application standard : déploiement au démarrage
 Au démarrage TOMCAT effectue le déploiement de

l’ensemble des application disponible dans le dossier
appBase de chaque Host définie.
 Il suffit de déposer l’application dans le dossier appBase

du Host cible, que ce soit sous la forme d’un fichier war ou
bien d’un dossier
 La structure de l’application doit respecter le standard JAVA
WEB
 Le déploiement se fait dans l’ordre suivant :

1. Les applications configurés par un Context que ce soit dans le
fichier server.xml ou un fichier context.xml
2. Les dossiers décompressés au sein du dossier appBase.
3. Les war contenues dans le dossier appBase, même les war
associés à une application décompressé. Ça permet
d’effectuer une mise à jour d’une application déjà déployé
Application standard : déploiement à chaud
 Pour éviter d’être obligé de redémarrer le serveur à

chaque qu’on veut déployer une nouvelle application
ou la mettre à jour TOMCAT propose plusieurs
mécanisme pour déclencher le redéploiement d’une
application
 Le flag autoDeploy au niveau du Host,

 L’application Tomcat Manager
 L’utilitaire ant, Tomcat Client Deployer.
 Le flag autoDeploy au niveau du Host s’il est positionné à true,

permet de déclencher un déploiement à chaud des applications
qui sont dans le scope du Host
 Il suffit de déposer un nouveau war dans le dossier appBase

pour déclencher le déploiement de la nouvelle application
 Il suffit de déposer une nouvelle version du war de

l’application pour en déclencher le redéploiement
 Supprimer le dossier correspondant à l’application dans le

appBase suffit à la désinstaller
 Utiliser la balise WatchedResource au niveau du Context pour

identifier les fichiers qui peuvent déclencher un redéploiement
de l’application même si un nouveau war n’est pas fournie
(par défaut web.xml)
 TOMCAT Manager est une application WEB fournit

avec TOMCAT qui permet d’effectuer des opération
de déploiement et de mise à jour de façon assez
simple et à distance
 Chaque Host a son propre manager accessible via

l’URL http://[host]:[port]/manager
 TOMCAT Manager permet d’effectuer un certain

nombre d’opérations autre que le déploiement, le
redéploiement ou la désinstallation des applications
 Arrêter une application
 Redémarrer une application
 Vider les sessions actives
 Tomcat Client Deployer (TCD) est un utilitaire JAVA

et des tâches ant, qui permet de gérer le cycle de
vie d’une application web
 compile (default) : Compile et valide une

application web.
 deploy : Déploie l’application vers le serveur cible
 undeploy : désinstalle une application web
 start : démarre une application web
 reload : recharge une application web
 stop : arrête une application web
TOMCAT embarqué (Embededd)
Démonstration
Cluster & Load balancer
 En production utiliser un seul serveur comporte des
risques élevés d’indisponibilité de notre application à
chaque fois que notre serveur rencontre des
problèmes.
 La solution est de mettre en place un groupe de
serveurs (cluster) qui se comporte alors en tant que
serveur de production,
 chaque machine exécute la même application,
 N’importe quel machine peut traiter les requêtes
clients
 Si une machine tombe, une autre prends le relais.
 La solution est de mettre en place un groupe de
serveurs Cluster qui se comporte alors en tant que
serveur de production,
 Chaque machine du groupe exécute la même
application,
 N’importe quel machine peut traiter les requêtes
clients
 Si une machine tombe, une autre du groupe prends le
relais.
 Se pose alors quelques problèmes :
 Chaque machine du groupe possède sa propre adresse
IP
 Chaque instance TOMCAT écoute sur son propre port
 Quelle instance le client doit invoquer ?

 La solution consiste à mettre en place une machine
frontale
 Elle est responsable de recevoir les requêtes client
 Elle se charge de redistribuer les requêtes vers les
membres du cluster
 Cette machine s’appelle un Load Balancer

Load Balancer (Apache HTTPD + mod_jk
connector)
 TOMCAT propose deux types de connecteurs HTTP

et AJP
 Le connecteur HTTP est celui utilisé lorsque TOMCAT
est configuré en tant que serveur HTTP
 Le connecteur AJP (Apache JSERV Protocole) est celui

utilisé lorsque TOMCAT est derrière un frontal, AJP est
un connecteur binaire et donc plus performant que le
protocole HTTP
connector)
 Installer et configurer Apache pour utiliser le

protocole AJP en communication avec TOMCAT.
 Configurer le module jk_module au niveau du fichier httpd.conf
LoadModule jk_module modules/mod_jk.so

JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel emerg
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -
ForwardDirectories
JkRequestLogFormat "%w %V %T"
connector)
 Définir le fichier de configuration du mod_jk

 Créer un fichier de propriétés workers.properties
worker.list=balancer,stat
worker.tomcat1.type=ajp13
worker.tomcat1.port=8080
worker.tomcat1.host=192.168.5.10
worker.balancer.type=lb
worker.balancer.balance_workers=tomcat1,tomcat2,tomcat3
worker.stat.type=status
connector)
 Demander à Apache de déléguer les requêtes vers le

Load Balancer définie
JkMount /status stat

JkMount /* balancer
Load Balancer (Apache HTTPD + mod_proxy_ajp
connector)
 À partir de la version 2.1 de Apache HTTPD une

autre configuration est possible
LoadModule mod_proxy modules/ mod_proxy.so

LoadModule mod_proxy_ajp modules/ mod_proxy_ajp.so
<Proxy balancer://cluster>
BalancerMember ajp://app1.example.com:8009 loadfactor=1
BalancerMember ajp://app2.example.com:8009 loadfactor=2
ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass /app balancer://cluster/app

Cluster TOMCAT
 Déclarer un cluster au sein de chaque serveur

membre, il se fait en ajoutant la balise <cluster> au
sein du server.xml
 <Manager> : identifie le type de gestionnaire de session
utilisé pour gérer la réplication des sessions,
 org.apache.catalina.ha.session.DeltaManager (par défaut)
 org.apache.catalina.ha.session.BackupManage
 <Channel> : la canal de communication des membres du
groupe en utilisant du multiCast
 <Deployer> : permet de gérer le déploiement des
applications au sein des membres du groupe, il suffit de
déployer l’application dans un membre et le cluster se charge
de la diffuser
Cluster TOMCAT
 <Valve> :
 ReplicationValve : notifie le Cluster de la fin du traitement
d’une requête HTTP pour optimiser l’opération de
réplication des données
 JvmRouteBinderValve : ajoute le jvmRoute au niveau de
l’id session pour que les requêtes suivantes de la même
session soient traités par le même membre.
 <ClusterListner> :
 ClusterSessionListener : utilisé si le gestionnaire de
session est DeltaManager.
 JvmRouteSessionIDBinderListener : se charge de redéfinir
le jvmRoute de la requête si le serveur responsable est
KO.
Cluster TOMCAT
Cluster TOMCAT
 Ajouter la balise <distributable/> au sein du fichier

web.xml de chaque application qui doit être géré par
le cluster
 Les objets déposés par les applications dans les sessions HTTP
doivent être sérialisable
jvmRoute
 Imaginons le scénario suivant :

 Une application avec un besoin d’utilisation de la session, par
exemple un caddie.
 Mon application me permet de naviguer en son sein et de

remplir mon caddie
 Le load balancer intercepte chaque requête et décide de

l’envoyer à un autre membre du groupe
 Ce membre reçoit la requête avec un ID session qu’il ne gère

pas encore, il créer une nouvelle session avec cette ID et
traite la requête
 PB : mon caddie est géré en session, Le caddie est vide.

jvmRoute
 Obliger le load balancer de diriger toues les requêtes

vers le membre qui a traité la 1er
 Ajouter l’attribut jvmRoute au niveau de la balise
<Engine>, la valeur de l’attribut doit
correspondre au nom attribué au membre lors de
la définition du load balancer
jvmRoute
 au sein du fichier workers.properties
<Engine name="Catalina"
defaultHost="localhost“ jvmRoute=“tomcat1” >
jvmRoute
 Pour Apache HTTPD 2 avec le module mod_proxy_ajp
ProxyPass /app balancer://mycluster

stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy balancer://mycluster>
BalancerMember ajp://192.168.1.50:80 route=node1
BalancerMember ajp://192.168.1.51:80 route=node2
</Proxy>
<Engine name="Catalina"
defaultHost="localhost“ jvmRoute=“node1” >
jvmRoute
 Après cette opération TOMCAT génère l’id session en

y intégrant le jvmRoute
 Avant :
Cookie: JSESSIONID=40025608F7B50E42DFA2785329079227
 Après :
Cookie:JSESSIONID=40025608F7B50E42DFA2785329079227.tomcat1
jvmRoute
 Au niveau de la définition du Cluster au sein de

TOMCAT :
 <Manager> : utiliser le
org.apache.catalina.ha.session.DeltaManager
 <Valve> : intégrer la valve JvmRouteBinderValve
 <ClusterListner> : intégrer les valves

ClusterSessionListener et
JvmRouteSessionIDBinderListener
jvmRoute
 Après cette opération TOMCAT génère l’id session en

y intégrant le jvmRoute
 Avant :
Cookie: JSESSIONID=40025608F7B50E42DFA2785329079227
 Après :
Cookie:JSESSIONID=40025608F7B50E42DFA2785329079227.tomcat1
Multiple instances
Préparer les environnements
 CATALINA_HOME : variable d’environnement qui

pointe sur le répertoire d’installation de TOMCAT,
permet de localiser les dossier bin et lib
 CATALINA_BASE : variable d’environnement qui

pointe sur le répertoire contenant les dossier de
configuration TOMCAT, conf, logs, temp, webapps,
et work
 Si ce variable n’est pas positionné, il est
automatiquement remplacé par CATALINA_HOME
Multiple instances
Préparer les environnements
 Pour chaque instance souhaité, préparer un

répertoire, et y copier les dossiers conf, temp,
webapps, logs à partir de la copie d’origine
 Mettre à jour le fichier de configuration server.xml

 Changer le port SHUTDOWN de la balise <Server>
 Changer les ports d’écoutes des différents connecteurs
configurés HTTP ou AJP
 Changer toute autre configuration souhaité
Multiple instances
Démarrer
 Préparer un script de démarrage pour les différentes

instances :
 Linux :
export CATALINA_BASE= /path/tomcat-instance1
cd $CATALINA_HOME/bin
./startup.sh
 Windows :
set CATALINA_BASE= /path/tomcat-instance1
cd $CATALINA_HOME/bin
./startup.bat
APR
INFO: The APR based Apache Tomcat Native library which allows
optimal performance in production environments was not found
on the java.library.path
 Avec ce message TOMCAT vous propose d’installer

le module APR (Apache Portable Runtime) pour plus
de performance et de stabilité.
 Le module APR fournit à TOMCAT un accès native aux

ressources systèmes sans passer par le JDK.
 permet d'améliorer les performances globales du

serveur WEB (meilleure génération des identifiants de
session, entrées/sorties fichier, SSL, …).
APR
APR pour Linux
 Installation :
get-app install libapr1-dev libssl-dev
cp $TOMCAT_HOME/bin/tomcat-native.tar.gz /usr/local/src
cd /usr/local/src
tar -xvzf tomcat-native.tar.gz
cd tomcat-native-1.1.16-src/jni/native
./configure --with-apr=/usr/bin/apr-1-config
--with-java-home=$JAVA_HOME
--with-ssl=yes
--prefix=$CATALINA_HOME
make
make install
 Démarrage : Ajouter la variable d’environnement suivante au

niveau du catalina.sh
export LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/usr/local/apr/lib'
APR
APR pour Windows
 Télécharger la DLL tcnative-1.dll
 Déposer la DLL dans le dossier bin de TOMCAT
 Redémarrer TOMCAT
APR
Utiliser les connecteurs
 Intégrer le connecteur APR

 HTTP
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11AprProtocol"
connectionTimeout="20000" redirectPort="8443" acceptCount="100"
maxKeepAliveRequests="15"/>
 HTTPS
<Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" />
<Connector port="443" maxHttpHeaderSize="8192" maxThreads="150"

enableLookups="false" disableUploadTimeout="true" acceptCount="100"
scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="${catalina.base}/conf/localhost.crt"
SSLCertificateKeyFile="${catalina.base}/conf/localhost.key" />
JMX Monitoring
 TOMCAT est une application JAVA est par

conséquent il peut être surveillé (Monitoring) a
distance ou en local grâce à son support de JMX en
utilisant les outils de monitoring JAVA standard du
marché.
 Notamment l’utilitaire JDK jVisualVM, il se trouve dans

le dossier bin du JDK
JMX Monitoring
 Créer un fichier setenv.sh et y ajouter la ligne suivante :
export JAVA_OPTS="-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=adressIPVotreServeur"
 Démarrer l’utilitaire jVisualVM.
 Utiliser le menu file->Add JMX Connection
 Saisir l’adresse IP de votre TOMCAT et le port d’écoute JMX
JMX Monitoring
 Il est possible de sécuriser l’accès JMX à votre serveur
export JAVA_OPTS="-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Djava.rmi.server.hostname=adressIPVotreServeur
-Dcom.sun.management.jmxremote.password.file=/path/jmx.password
-Dcom.sun.management.jmxremote.access.file=/path/jmx.access"
JMX Monitoring
 Le fichier jmx.password contient les couples login/mot de
passe autorisés à accéder en JMX sous la forme
user1 password1
user2 password2
 Le fichier jmx.access contient les autorisations de chaque
utilisateur
user1 readonly
user2 readwrite
 L’accès au fichier jmx.password doit être limité à
l’utilisateur JAVA
sudo chown tomcat7:tomcat7 /path/jmx.*
sudo chmod 0600 /path/jmx.*
pour la plate forme Windows suivre le document suivant :
http://docs.oracle.com/javase/6/docs/technotes/guides/mana
gement/security-windows.html
JMX Monitoring
 Si TOMCAT est dernière un firewall, il se peut qu’un
problème de communication advienne.
 JMX utilise le port configuré pour la phase de connexion,

mais après il ouvre un autre port de façon aléatoire pour
la communication des données
 Il est possible de contrôler ce port de communication en

ajoutant l’écouteur JmxRemoteLifecycleListener au niveau
du server.xml
<Listener
className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
rmiRegistryPortPlatform="9090" rmiServerPortPlatform="9091" />

Supportformationtomcat

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Supportformationtomcat

Transféré par

Droits d'auteur :

Formats disponibles

APACHE TOMCAT

Mohamed Iheb Eljani

 Class Loader  Instances Multiples

 Servlet est une classe Java qui permet de générer

 JavaServer Pages ou JSP est une technologie Java qui

 Un conteneur de servlet est une plateforme qui fournit un

 Apache TOMCAT est le conteneur de servlet fourni par la

 TOMCAT est le produit de la fusion du projet Java Web

 La 1er version produite est la version 3, en 1999.

 En 2001, la version 4 est sorti sous le nom de code

 Disponible sur le site http://tomcat.apache.org/

7.0 3.0 2.2 1.6

8.0 3.1 2.3 1.7

9.0 4.0 2.3 1.8

 Deployer : Module ANT pour automatiser le

 Embedded : Ensemble de composants nécessaire pour

 TOMCAT est une application JAVA et nécessite donc

 La version 9.0 nécessite un JDK 1.8 et supérieure

 La variable d’environnement JAVA_HOME doit pointer

 La valeur JAVA_HOME/bin doit exister au niveau de la

 En utilisant l’archive téléchargé

 Utiliser l’exécutable d’installation

 Déployer l’archive téléchargé dans un dossier cible

uname -r : identifier la version du kernel linux

 La plupart des distributions Linux modernes offre un

 CentOS, Fedora, Red Hat :

 bin : scripts et exécutables pour différentes tâches :

 lib : l’ensemble des jars utilisés

 temp : répertoire utilisé pour des fichiers temporaires,

 work : répertoire utilisé lors de transformation des JSP en

 webapps : répertoire de déploiement des applications

 Le répertoire webapps par défaut contient les

 Server : encapsule le conteneur web. Il ne peut

 Connector : gère et intercepte les communications

 Engine : composant responsable de traiter les

 Service : composant logique qui associe un

 Host : concept qui ressemble à son équivalent hôte

 Context : représente l’application WEB déployé et

 Valve : Composant capable d’implémenter un

 Realm : Une source de données qui fournit une liste

 Le fichier Server.xml représente le point central pour la

 Le fichier ou est configuré l’ensemble des composants

 Server.xml, comme son nom l’indique est un fichier XML,

 <Listener> : Listener pour intercepter les

 <GlobalNamingResources> : ressources JNDI

 <Service> : regroupe un ou plusieurs connecteurs

 <Engine> : composant responsable du traitement des

 port : port TCP sur lequel écoute le connecteur, c’est le port

 Protocol : type du connecteur, 2 valeurs possibles

 maxThreads : nombre max de threads crées simultanément pour

 connectionTimeOut : temps d’attente de la requête pour être

 redirectPort : le port sur lequel doit être redirigé les requêtes

 defaultHost : hôte par défaut, utilisé si plusieurs hôtes

 <Host> : un ou plusieurs, identifie un hôte virtuel

 name : le nom utilisé par le hôte virtuel

 deployOnStartup : si Oui, les applications disponible

 <Alias> : permet d’associer ce hôte à d’autres nom

 <Context> : un ou plusieurs, ensemble de

 <DefaultContext> : ensemble de paramétrage

 <Realm> : configure les droits d’accès au niveau de

 docBase : le répertoire ou sont stockés les

 path : le chemin de tomcat à utiliser dans

 cookies : si Oui, utiliser les cookies pour gérer la