Un connecteur est un objet Java capable d'écouter un port précis et comprenant un protocole précis. À chaque protocole supporté par Tomcat est associé une classe Java de connecteur. Chaque connecteur dirige ensuite les requêtes qu'il reçoit au moteur de servlets défini dans ce service. Donc un moteur de servlet donné peut répondre à des requêtes en provenance de plusieurs ports, et suivant des protocoles différents.

Quel que soit le connecteur choisi, un certain nombre d'attributs sont toujours disponibles :

  • port : le port que ce connecteur écoute.

  • enableLookups : autorise ou non les requêtes DNS lorsqu'une servlet invoque la méthode request.getRemoteHost(). Une requête DNS est un processus éventuellement coûteux. Si enableLookups est à false, alors request.getRemoteHost() retourne l'adresse IP plutôt que le nom de domaine associé.

  • maxPostSize : la taille maximale des requêtes POST supportée par ce serveur. La valeur par défaut est fixée à 2Mo. Une valeur de -1 signifie qu'il n'y a pas de limite.

Cet élément modélise un hôte virtuel. Un hôte virtuel doit être associé à l'adresse IP de ce serveur, via un DNS ou un fichier hosts. Si l'attribut defaultHost du moteur dans lequel se trouve cet hôte est défini, alors au moins un des hôtes doit obligatoirement posséder ce nom.

Toutes les implémentations de Host doivent supporter les attributs suivants :

  • name : le nom de cet hôte virtuel ;

  • appBase : l' application base pour cet hôte. Il s'agit du répertoire contenant les applications web pour cet hôte. Il peut s'agir d'un chemin absolu, ou d'un chemin relation au répertoire $CATALINA_BASE. La valeur par défaut de cet attribut est true.

  • autoDeploy : indique à Tomcat s'il doit charger automatiquement les applications web qui sont copiées dans le répertoire appBase. Le cas échéant, Tomcat scrute le contenu de ce répertoire à intervalles de temps réguliers, afin de détecter de nouveaux répertoires, ou de nouveaux fichiers .war.

  • deployOnStartup : indique à Tomcat s'il doit charger les applications web se trouvant dans appBase lors de son démarrage. La valeur par défaut de cet attribut est true.

L'implémentation par défaut supporte en plus les attributs suivants.

  • workDir : répertoire de travail propre à cet hôte. Par défaut, Catalina utilise un sous-répertoire de $CATALINA_BASE/work pour chaque hôte, mais il est possible d'en choisir un autre. On peut accéder à ce répertoire d'une servlet, via l'attribut d'application javax.servlet.context.tempdir.

  • unpackWARs : indique à Catalina qu'il doit exécuter les applications web de cet hôte dans un répertoire de travail avant de les exécuter. La valeur par défaut de cet attribut est true.

  • deployXML : indique à Catalina s'il peut ou non prendre en compte les fichiers /META-INF/context.xml des applications web. La valeur par défaut de cet attribut est true.


Enfin, l'élément Context modélise une application web. Cet élément est un peu particulier, car il peut se trouver en plusieurs endroits.

Historiquement (Tomcat v4), cet élément se trouvait nécessairement dans le fichier server.xml de Tomcat. Cette façon de faire posait deux problèmes :

  • toute modification d'un contexte pour une unique application web imposait de redémarrer l'ensemble du serveur Tomcat, puisque ce fichier est pris en compte au démarrage de Tomcat ;

  • ce fichier étant la propriété de l'administrateur de Tomcat, il y avait un problème de partage de droits, puisque ce sont les administrateurs des applications web qui connaissent le contenu de ces éléments.

Ce problème a été levé, et il est maintenant possible de placer cet élément dans un fichier context.xml rangé dans le répertoire META-INF de l'application.

La prise en compte ou non de ce fichier à cet endroit peut être réglé par l'administrateur de Tomcat (attribut deployXML de l'élément Host). S'il choisit de ne pas prendre en compte ces fichiers, alors Tomcat ira chercher ce fichier ailleurs, dans un endroit contrôlé par l'administrateur.

On peut définir autant d'éléments Context que l'on veut dans un hôte virtuel, avec une restriction :

  • chaque élément Context doit être associé à un unique attribut path, qui représente le chemin vers cette application web.

  • au moins un Context doit être associé à un chemin vide. C'est cette application qui servira toutes les requêtes non servies par les autres applications.

Cet élément permet de configurer des ressources et des variables d'environnement, qui seront ensuite disponibles pour toutes les applications web gérées par cette instance de Tomcat. La distribution par défaut nous donne l'exemple de la base d'utilisateurs reconnue par cet instance de Tomcat.

Voyons tout d'abord un exemple de définition d'une variable d'environnement.


Notons que l'attribut name, qui représente le nom de la variable créée, est relatif au context java:comp/env. Dans notre exemple, le nom JNDI complet de la variable sera donc java:comp/env/maxRetry.

Examinons maintenant la ressource définie dans le server.xml par défaut.


Toute ressource doit posséder un nom (attribut name) et un type, sous forme d'une classe Java. Cette ressource UserDatabase sera donc représentée par un objet de type UserDatabase, que Tomcat peut construire grâce à la classe factory MemoryUserDatabaseFactory.

Cet objet a besoin du paramètre suivant pour s'initialiser : pathname, qui lui indique dans quel fichier les utilisateurs sont définis.

On peut définir des ressources très diverses, les plus fréquentes sont les connexions aux bases de données, disponibles sous forme de DataSource, ou aux serveurs de mail.


Nous verrons dans la suite comment il est possible d'accéder à ces ressources d'une application web.

Un Realm est une notion qui appartient à l'environnement de sécurité de Java, défini par JAAS ( Java Authentification and Authroization Service ) pour la partie JSE et JCCA pour la partie JEE. Par définition, un Realm est un ensemble d'utilisateurs qui partagent la même méthode d'authentification. Techniquement pour Tomcat, un Realm est défini par cette méthode d'authentification.

Comme il a été dit, un élément Realm est un élément qui peut être inclus dans plusieurs éléments conteneur du fichier conf/server.xml de Tomcat : Engine, Host ou Context. Un élément Realm inclus dans un élément parent est automatiquement hérité dans les éléments enfants. Ainsi, un Realm défini dans un Host (donc au niveau d'un hôte virtuel) sera automatiquement pris en compte par tous les Context (donc les applications web) de ce Host.

Un élément Realm permet d'associer des droits d'utilisation aux application web. Un tel élément modélise une base d'utilisateurs et rôles, qu'il est ensuite possible d'utiliser pour restreindre l'utilisation de certaines applications.

Tomcat propose plusieurs implémentations de Realm. Nous en avons déjà vu une : org.apache.catalina.realm.MemoryRealm, qui utilise le fichier tomcat-users.xml. Les autres implémentations permettent notamment de lire la liste des utilisateurs et des rôles dans des bases de données, qui elles-mêmes peuvent être administrées par ailleurs.

Le choix d'une implémentation particulière se fait en fixant une valeur à l'attribut className de l'élément Realm.

Examinons une de ces implémentations : org.apache.catalina.realm.JDBCRealm. Dans cette implémentation, les utilisateurs sont enregistrés dans une table. Tomcat a besoin de plusieurs informations pour y accéder :

  • la chaîne de connexion à la base de données, un nom d'utilisateur et un mot de passe ;

  • le nom de la table, et des différentes colonnes où se trouvent les informations dont il a besoin.

Voici un exemple d'un tel élément.


On reconnaît sans problème les paramètres de connexion à la base parmi les attributs de cet élément. Viennent ensuite les paramètres de la table contenant les utilisateurs. Tomcat utilise deux colonnes : userNameCol porte les noms des utilisateurs, et userCredCol leurs mots de passe. Notons que par défaut les mots de passe sont stockés en clair, mais qu'il est possible de configurer ce Realm pour qu'ils soient cryptés. Enfin, viennent les paramètres de la table des rôles : userRoleTable porte le nom de cette table et userRoleTable le nom de la colonne qui contient les noms des rôles. Cette table doit aussi comporter une colonne userNameCol, qui réalise la jointure entre la table des utilisateurs et celle des rôles.

Il existe également une implémentation de Realm capable de s'adresser à une DataSource directement : org.apache.catalina.realm.DataSourceRealm. La DataSource est obtenue par une requête JNDI dont le nom est donné en paramètre. Voyons un exemple.


Les attributs permettant de lire les tables d'utilisateurs et de rôles sont les mêmes que pour le Realm JDBC.

De même que l'élément Realm, l'élément Valve peut se placer dans les conteneurs Engine, Host et Context. De même que pour le Realm, une valve définie au niveau d'un conteneur s'applique à ses sous-conteneurs. Une valve est un élément utilitaire, qui peut avoir différentes fonctions, qui s'insère dans le processus de traitement d'une requête, et realise un certain traitement. À chaque type de valve est associé un traitement particulier.

Un élément Valve comporte toujours un attribut className, qui indique quelle implémentation de Valve est utilisée pour cet élément. Suivent ensuite une liste d'attributs propres à chaque implémentation.

Voyons les principales implémentations de Valve :

Java servlet et JSP
Retour au blog Java le soir
Cours & Tutoriaux

Table des matières

Introduction
1. Position de l'API Servlet
2. Présentation
Présentation de Tomcat
1. Un peu d'histoire
2. Organisation des répertoires de Tomcat
2.1. Répertoire bin
2.2. Répertoire conf
2.3. Répertoire lib
2.4. Répertoire log
2.5. Répertoire temp
2.6. Répertoire webapp
2.7. Répertoire work
3. Lancement de Tomcat
3.1. Lancement par défaut
3.2. Accéder à l'administration de Tomcat
3.3. Plusieurs instances de Tomcat
4. Configuration de Tomcat
4.1. Introduction
4.2. Élément Server
4.3. Élément Service
4.4. Élément Connector
4.5. Élément Engine
4.6. Élément Host
4.7. Élément Context
4.8. Élément GlobalNamingResources
4.9. Élément Realm
4.10. Élément Valve
5. Définition et chargement des applications web
5.1. Introduction
5.2. Prise en compte des éléments Context
5.3. Chargement et mise à jour à chaud
6. Utilisation de Tomcat avec Apache
API Servlet
1. Introduction
2. Une première servlet
2.1. Le code
2.2. Création de l'application web
2.3. Déploiement dans Tomcat
3. Concepts, cycle de vie
3.1. Requête
3.2. Réponse
3.3. Session
3.4. Application web
3.5. Contexte d'exécution
3.6. Cycle de vie
3.7. Filtre
4. Présentation générale de l'API
4.1. Introduction
4.2. Interfaces disponibles
5. Notion de servlet
5.1. Interfaces servlet
5.2. Cycle de vie d'une servlet
5.3. Paramètres d'initialisation d'une servlet
6. Notion de requête
6.1. Accès aux paramètres d'une requête
6.2. Accès aux éléments de l'en-tête HTTP
6.3. Accès aux éléments de l'URL
6.4. Accès aux paramètres du client
6.5. Accès aux informations de sécurité
6.6. Accès à la session, au contexte et aux informations d'initialisation
7. Notion de réponse
7.1. Contrôle du buffer de sortie
7.2. Contrôle de la réponse HTTP
8. Notion de session HTTP
9. Redirection ou inclusion d'une ressource
10. Listeners
10.1. Introduction
10.2. Événements de l'API Servlet
10.3. Ajout ou retrait d'un attribut
10.4. Création et destruction d'un contexte
10.5. Notification d'un objet attaché à un contexte
10.6. Déclaration d'un listener dans une application web
11. Connexion à une base
11.1. Introduction
11.2. Connexion manuelle
11.3. Connexion par utilisation de source de données
Filtrage
1. Filtrage de servlets
2. Mise en place d'un filtre
2.1. Écriture d'un filtre
2.2. Déclaration du filtrage
3. Filtrage d'une requête
4. Filtrage d'une réponse
4.1. Fonctionnement de ce filtrage
Java Server Pages
1. Introduction
2. Un premier exemple
2.1. Une première JSP statique
2.2. Une première JSP dynamique
2.3. Fonctionnement interne des JSP
3. JSP scriplet
3.1. Les expressions
3.2. Les déclarations
3.3. Variables prédéfinies
3.4. Scriplet de directives
4. Utilisation de beans
4.1. Introduction
4.2. Déclaration d'un bean existant
4.3. Création d'un nouveau bean
4.4. Utilisation des propriétés d'un bean
5. Inclure un contenu externe dans une JSP
5.1. Introduction
5.2. Inclusion au lancement de l'application
5.3. Inclusion au traitement de la requête
6. Utilisation de bibliothèques de tags
6.1. Introduction
6.2. Bibliothèque core
7. Internationalisation
7.1. Notion de bundle
7.2. Internationalisation de pages JSP
Projet exemple
1. Présentation du projet