Groupe Eyrolles, 2003 ISBN : X

Transcription

1 Groupe Eyrolles, 2003 ISBN : X

2 7 Le fichier server.xml Dans le chapitre 3, nous avons abordé les bases de la configuration de Tomcat, informations suffisantes pour vous mettre le pied à l étrier. Dans ce chapitre, nous allons étudier plus en détail le fichier server.xml. Comme vous le savez, il s agit du fichier de configuration principal de Tomcat. Il fournit à Tomcat tous les paramètres nécessaires en termes de fonctionnement, de ports à écouter, d hôtes virtuels à reconnaître, de nombre d instances de processeur HTTP à conserver dans le pool d instances pour chaque connexion et de classes à utiliser pour gérer les connexions entrantes. Java est un langage très dynamique et Tomcat améliore encore ce dynamisme, et vous permet d obtenir des résultats hors pair et une plate-forme extrêmement souple et paramétrable. Le fichier server.xml, situé dans le répertoire <$CATALINA_HOME>/conf/, est bien évidemment un fichier XML. Comme mentionné à maintes reprises, XML est un langage sensible à la casse et le fichier server.xml doit utiliser des balises commençant par une majuscule suivie de lettres en minuscules. D ailleurs, le fichier server.xml fourni actuellement avec Tomcat, n est pas, stricto sensu, un fichier XML valide. En effet, il ne comporte pas la déclaration <?xml version="1.0" encoding="iso "?>. De plus, ce fichier ne se fonde pas sur une DTD (Document Type Definition) ; il peut donc être étendu selon les besoins si de nouvelles implémentations des interfaces du serveur Tomcat (développées par l équipe Jakarta ou des développeurs individuels) mettent en œuvre de nouvelles fonctions. Par conséquent, le fichier server.xml ne comprend pas non plus de ligne DOCTYPE. Ces quelques différences mises à part, le fichier se conforme aux directives XML. Ce modèle rend valide l extension des attributs de balises intégrées dans les nouvelles classes que vous implémentez. Ce qui signifie simplement que vous ne pouvez pas utiliser de parseur de validation pour confirmer la validité de votre document. Lors du démarrage ou de l arrêt,

3 84 Tomcat par la pratique Tomcat indique si la structure du fichier est valide ou non. Si vous souhaitez ensuite éditer le fichier à l aide d un éditeur exclusivement XML, vous pouvez toujours ajouter vous-même la balise <?xml?>. Cependant, puisqu il n existe pas de DTD, les tentatives de validation de la structure échoueront, et vous préfèrerez sans doute désactiver la validation. Les nouvelles fonctions de Tomcat 4.1 La faible incrémentation du numéro de version ne rend pas justice aux nombreuses fonctionnalités implémentées dans la version 4.1 de Tomcat. Dans ce chapitre, nous nous concentrerons sur le nouvel outil d administration de serveur Web (Web Server Administration Tool), que vous pouvez utiliser pour configurer le fichier server.xml. Cette application est une amélioration considérable par rapport à l édition manuelle du fichier server.xml. Même si vous projetez de déployer votre application sous Tomcat 4.0, vous pouvez installer et expérimenter avec la version 4.1 pendant les premières étapes de la configuration de Tomcat. Vous pouvez ensuite consulter les modifications effectuées par l outil d administration de serveur Web sur le fichier server.xml, et avoir ainsi une première approche concrète de ce que Tomcat peut faire. L édition manuelle du fichier server.xml peut se révéler difficile de prime abord. Cependant, vous pouvez facilement empêcher le serveur de fonctionner si ce fichier de configuration ne vous est pas familier. Nous allons commencer par expliquer le fichier server.xml lui-même, puis, à la fin de ce chapitre, nous aborderons les principes de base du nouvel outil d administration. À l aide des informations fournies dans la première partie de ce chapitre, vous serez à même d utiliser cet outil de manière très efficace, même si l interface utilisateur finale diffère légèrement de celle dont nous disposons à l heure où nous rédigeons ce livre. Le modèle de base Tomcat comprend un processus principal, le serveur, contenant lui-même plusieurs souscomposants, qui collaborent pour traiter les requêtes. Les sous-composants principaux sont un ensemble de conteneurs et un ensemble de connecteurs. Les conteneurs sont la colle qui cimente les autres composants entre eux ; ils fournissent également un ensemble commun de paramètres pour une partie du serveur. Le conteneur principal est le moteur, le véritable noyau de Tomcat. D ailleurs, c est cet objet que nous avons en tête lorsque nous pensons à un serveur. Il gère la répartition de toutes les requêtes et agit comme une interface entre chaque connecteur et le reste du système, y compris les servlets. Les autres conteneurs sont des conteneurs hôtes et des contextes. Ceux-ci établissent un environnement dans lequel les servlets peuvent s exécuter et facilitent certaines tâches comme l établissement d une configuration d exécution (y compris les mécanismes d authentification, par exemple). Vous aurez recours aux conteneurs hôtes lorsqu un serveur doit servir plusieurs hôtes virtuels ou des interfaces séparées. Ils contiennent la configuration d un hôte unique. Au sein de ces conteneurs, vous configurez les fichiers journaux, les realms d authen-

4 Le fichier server.xml CHAPITRE 7 85 tification et les ressources disponibles pour le conteneur, un pool de connexions à une base de données, par exemple. Les connecteurs sont des gestionnaires de protocole qui convertissent, dans un protocole de réseau donné, les entrées et les sorties en appels de méthodes Java. En fin de chapitre, nous étudierons différents connecteurs à configurer. Même les servlets que vous écrivez vous-même constituent, en fait, des composants de ce modèle. Les composants principaux sont configurés dans le fichier server.xml. Les servlets que vous écrivez peuvent également être configurées dans ce fichier, mais il est généralement plus simple de le faire dans leur propre fichier web.xml. Les documents XML étant dotés d une structure hiérarchique, nous commencerons par traiter les éléments les plus élevés dans la hiérarchie, et progresserons vers les éléments inférieurs. Chaque élément possède un ensemble d attributs obligatoires et facultatifs ; nous les préciserons pour chaque attribut. La plupart des éléments peuvent également contenir des éléments enfants qui affectent également leur configuration, principalement en définissant un composant pour gérer une fonction et l associer à l objet configuré dans l élément parent. Lorsque nous aborderons tous les éléments enfants potentiels à chaque niveau de la hiérarchie, nous nous concentrerons d abord sur les éléments les plus utilisés, puis nous traiterons des éléments moins usités. Le but est avant tout de vous donner des bases solides, sans négliger les détails. L élément <Server/> L élément <Server/> est le nœud racine de la hiérarchie. Il contient tous les autres éléments qui contrôlent le serveur, et prend en charge trois attributs. Le premier attribut, facultatif, est classname. Il s agit du nom entièrement qualifié de la classe à utiliser en tant que serveur Tomcat lui-même. Généralement, cet attribut est omis et Tomcat utilise l implémentation par défaut ; cependant, si vous le souhaitez, vous pouvez écrire une implémentation totalement différente du moteur de servlets. La classe spécifiée ici doit implémenter l interface org.apache.catalina.server, mais vous pouvez implémenter une classe de remplacement pour le serveur Tomcat Catalina. Bien évidemment, à moins d y être contraint, mieux vaut omettre cet attribut. Les deux autres attributs, port et shutdown, contrôlent le service utilisé par Tomcat pour écouter les commandes d arrêt. Ces deux attributs sont obligatoires. L attribut port définit le port à écouter ; l attribut shutdown contient la chaîne recherchée par le port. Lorsqu une connexion entre sur le port spécifié, et que cette connexion envoie la chaîne définie par l attribut shutdown, Tomcat s arrête. Tomcat écoute uniquement les requêtes locales ; par conséquent, cela n est pas aussi dangereux qu il y paraît. Cependant, il est judicieux de modifier au moins la chaîne d arrêt pour empêcher les utilisateurs du système d arrêter le serveur de manière accidentelle ou intentionnelle et sans permission. Le script d arrêt lit le même fichier de configuration pour connaître le port auquel se connecter et la chaîne à envoyer, de

5 86 Tomcat par la pratique sorte que la configuration est très simple. Comme mentionné précédemment, ces attributs sont obligatoires dans l implémentation actuelle ; si vous ne les configurez pas, ils prennent respectivement les valeurs par défaut 8005 et SHUTDOWN. Si vous implémentez votre propre serveur, vous pouvez le configurer de sorte à ce qu il lise d autres attributs. L implémentation du serveur par défaut, org.apache.catalina.core.standardserver, à l instar des nombreux autres composants que nous allons étudier, utilise également un attribut facultatif debug, qui définit un niveau de journalisation. La valeur par défaut est 0, ce qui signifie «journalisation du déboguage désactivée». L élément <Server/> contient un ou plusieurs nœuds <Service/> que nous allons aborder maintenant. Le conteneur <Service/> À la base, les éléments <Service/> sont des conteneurs regroupant les ressources intervenant dans la gestion des requêtes. Ils contiennent un ou plusieurs éléments <Connector/> définissant les gestionnaires de protocole qui écoutent les requêtes, et partagent un élément <Engine/> unique chargé de répartir les requêtes. Les nœuds <Connector/> doivent précéder le nœud <Engine/>. L élément <Service/> possède deux attributs principaux. L attribut obligatoire name affecte un nom au service qui s affiche dans les messages de journalisation générés par les composants standards de Tomcat. L attribut facultatif classname définit la classe qui sera instanciée pour cet élément et qui doit implémenter l interface org.apache.catalina.service. À l instar du nœud <Server/>, cet attribut est généralement omis et la classe utilisée est la classe par défaut, org.apache.catalina.core.standardservice. Bien évidemment, le conteneur Service ne se résume pas à ça. La configuration essentielle du service s effectue dans les éléments enfants du nœud <Service/>, comme nous le verrons plus loin. Le conteneur <Engine/> Comme mentionné précédemment, le composant engine est chargé de répartir toutes les requêtes. Celles-ci arrivent par l un des connecteurs et sont traitées par le moteur qui les transmet aux gestionnaires appropriés, l une de vos servlets par exemple, selon l URI requis et la nature de la requête. La sortie issue du gestionnaire est ensuite retransmise au connecteur adéquat. L attribut obligatoire name définit le nom logique du moteur. Il figure dans toutes les sorties de fichier journal générées par le moteur lors de l exécution. L attribut obligatoire defaulthost définit le conteneur <Host/> auquel Tomcat doit transmettre les requêtes entrantes si le nom de l hôte contenu dans la requête ne correspond à aucun des

6 Le fichier server.xml CHAPITRE 7 87 hôtes configurés (si la requête arrive par un alias de votre serveur pour lequel vous n avez pas configuré d alias, par exemple), ou si une requête entrante ne spécifie aucun hôte. (La norme HTTP 1.0 ne spécifiait aucun mécanisme permettant de définir le nom d hôte visé par la requête. Par conséquent, les utilisateurs connectés à des navigateurs plus anciens risquent de ne pas être dirigés vers l hôte prévu mais vers l hôte par défaut.) De plus, un conteneur <Host/> doit être configuré avec un attribut name correspondant au nom de domaine spécifié dans cet attribut (voir la section suivante pour plus d informations). L attribut facultatif classname définit la classe d implémentation à utiliser pour mettre en œuvre cette fonction. La classe spécifiée doit implémenter l interface org.apache.catalina.engine. La valeur par défaut de l attribut est org.apache.catalina.core.standardengine. L attribut facultatif jvmroute est utilisé dans une architecture en cluster (ou clustering en anglais) pour identifier le serveur gérant une requête donnée. Il est ajouté à l identificateur de session pour garantir que les requêtes provenant d un client donné sont dirigées systématiquement vers le premier serveur contacté. L implémentation par défaut org.apache.catalina.core.standardengine ajoute l attribut facultatif debug, qui fonctionne de la même manière qu avec les autres composants Tomcat. Comme le décrit le chapitre 8 «Gérer l authentification avec les realms», le conteneur <Engine/> peut également être configuré en ajoutant un élément <Realm/> pour l authentification HTTP, puis un élément enfant <Logger/> ou un ou plusieurs éléments <Valve/> (nous y reviendrons). L élément <Realm/> L élément <Realm/> peut être un nœud enfant du conteneur <Engine/>, <Host/> ou <Context/>. Chaque conteneur ne doit pas posséder plus d un élément <Realm/>, bien que le conteneur <Host/> et son conteneur <Engine/> puissent chacun posséder un élément <Realm/>, ainsi que le conteneur <Context/> et son conteneur <Host/>. Dans ce cas, le realm dont la portée est inférieure, c est-à-dire celui qui est configuré dans le conteneur interne, prévaut sur le realm à la portée plus large, soit celui qui est configuré dans le conteneur externe. Par exemple, dans le conteneur <Engine/>, vous pouvez définir un realm global à utiliser par la plupart des hôtes configurés. Il peut s agir ainsi d un realm JDBC (Java Database Connectivity), pour lequel les informations générales relatives à la connexion client sont stockées dans une base de données. Cependant, pour un hôte spécifique, vous pouvez choisir d utiliser un realm différent. Pour votre site intranet, par exemple, vous pourriez utiliser un realm JNDI (Java Naming and Directory Interface) relié au serveur LDAP (Lightweight Directory Access Protocol) de l entreprise pour fournir l accès. Vous devriez alors configurer ce realm dans le conteneur <Host/> approprié ; il remplacerait dès lors le realm à portée plus grande défini dans le conteneur <Engine/>.

7 88 Tomcat par la pratique La configuration des realms est un thème vaste que nous aborderons plus en détail dans le chapitre suivant, lorsque nous traiterons des attributs de classe. L élément realm en soi est assez simple et possède un seul attribut obligatoire, class. Cet attribut doit être le nom de la classe implémentant l interface org.apache.catalina.realm. Chacune des trois implémentations principales, org.apache.catalina.realm.memoryrealm, org.apache.catalina.realm. JDBCRealm et org.apache.catalina.realm.jndirealm, possède des attributs différents que nous détaillerons également dans le chapitre suivant. L élément <Logger/> Les fichiers journaux sont configurés dans les éléments <Logger/>, qui, comme les éléments <Realm/>, peuvent constituer des nœuds enfants pour les conteneurs <Engine/>, <Host/> ou <Context/>. Notez également que chaque conteneur ne doit pas posséder plus d un élément <Logger/>, bien que les mêmes règles de portée que celles de l élément <Realm/> s appliquent ici. L élément <Logger/> possède uniquement deux attributs communs à toutes les implémentations. Le premier, classname, est obligatoire et définit une classe implémentant l interface org.apache. catalina.logger (nous reviendrons sur les classes de fichiers journaux standards). Le deuxième attribut, verbosity, est facultatif et définit les types de messages que Tomcat doit consigner. Les niveaux de journalisation standards sont 0, pour les messages fatals uniquement ; 1 pour les messages d erreur ; 2 pour les avertissements ; 3 pour les messages d information et 4 pour les longues sorties de déboguage. La valeur par défaut est 1. Deux des classes d implémentation, org.apache.catalina.logger.systemoutlogger et org.apache.catalina.logger.systemerrlogger, écrivent simplement et respectivement vers la sortie standard et la sortie d'erreur standard, à l aide de System.out et System.err comme vous l aurez deviné. Le script de démarrage par défaut redirige ces deux flux vers le fichier <$CATALINA_HOME> /logs/catalina.out. Si vous ne configurez pas de fichier journal, la sortie des fichiers journaux se trouve à cet endroit, ainsi que tout ce que les servlets et les classes référencées écrivent sur les sortie System.out ou System.err. Il est préférable d utiliser le fichier journal org.apache.catalina.logger.filelogger car il permet de configurer le nom du fichier et le répertoire dans lequel effectuer la journalisation. Il inclut également automatiquement un horodatage dans le nom du fichier. Les attributs de FileLogger sont les suivants : directory (facultatif) Il définit le répertoire dans lequel effectuer la journalisation. Les chemins sont considérés comme des chemins relatifs à <$CATALINA_HOME> et la valeur par défaut est logs, pointant vers <$CATALINA_HOME>/logs/. timestamp (facultatif) Il spécifie l ajout ou non d un horodatage dans le nom du fichier journal créé. La valeur par défaut est false.

8 Le fichier server.xml CHAPITRE 7 89 prefix (facultatif) Il définit la partie du nom du fichier journal qui précède l horodatage, si l attribut timestamp possède la valeur true, ou qui précède simplement le suffixe si l attribut timestamp possède la valeur false. La valeur par défaut est catalina. suffix (facultatif) Il spécifie l extension à ajouter au nom du fichier journal. Il suit l horodatage si l attribut timestamp possède la valeur true, ou suit simplement le préfixe si l attribut timestamp possède la valeur false. La valeur par défaut de cet attribut est.log. Si vous ne souhaitez ni préfixe ni suffixe, affectez aux attributs concernés la valeur correspondant à une chaîne vide : "". Tomcat change automatiquement les fichiers journaux à minuit et indique la date et l heure sur les anciens fichiers. Le conteneur <Host/> Le conteneur <Host/> permet de configurer les attributs à associer à un hôte unique, que cet hôte soit virtuel ou qu il possède une adresse IP distincte sur un serveur hébergeant plusieurs adresses IP. Dans de nombreux cas, vous souhaiterez qu une instance du serveur unique traite les requêtes pour plusieurs noms de domaines ou d hôtes. C est le cas notamment lorsque plusieurs entreprises partagent des services d hébergement, ou encore, lorsque des sites Web distincts sont chargés de remplir différentes fonctions, avec un site Web public principal ( par exemple) et un deuxième site Web dédié à votre communauté de développeurs (developpeurs.mon_entreprise.com). Peut-être disposez-vous d une boîte de réception fiable et rapide dans des locaux de colocation, et souhaitez-vous renforcer la maintenance de votre présence sur le Web depuis cette seule boîte de réception. La possibilité de configurer une seule machine pour servir plusieurs hôtes offre une souplesse considérable. INFO Il n est jamais conseillé de partager une instance de serveur unique entre le service de production et celui du développement. Consultez le chapitre 19, «Le cycle de développement», pour en savoir plus sur la configuration de votre environnement de développement. L un des arguments en faveur de la séparation entre serveur de développement et serveur actif est que cette séparation permet de mieux garantir la stabilité du serveur actif. En effet, exécuter un code non testé sur le serveur actif est loin d en assurer la promotion! En outre, vous désirerez certainement arrêter le serveur de développement pour apporter des modifications, sans avoir à attendre une fenêtre de maintenance sur le serveur actif. De plus, vous ne voudrez sans doute pas placer votre serveur intranet sur la même boîte de réception que celle de votre site Web public. Pourquoi, en effet, mettre en danger la sécurité de votre code et risquer de révéler des informations confidentielles? Le matériel informatique reste bon marché et vous vous épargnerez de nombreux casse-tête, sans parler des coûts à long terme, en installant un autre serveur lorsqu un service a des exigences différentes, notamment en termes de disponibilité, d accès ou de sécurité.

9 90 Tomcat par la pratique Chaque conteneur <Engine/> doit comprendre au moins un élément <Host/> configuré avec l attribut obligatoire name correspondant au paramètre defaulthost du moteur. Ce nom doit être un nom d hôte valide et pointer vers le serveur sur lequel l instance de Tomcat s exécute. Dans le fichier server.xml exemple livré avec Tomcat, ces deux attributs ont la valeur localhost. Une valeur classique pour cet attribut est Là encore, il doit s agir d un nom DNS valide pour la machine sur laquelle l instance de Tomcat s exécute, et ce nom doit être mappé sur une adresse IP d une interface à laquelle Tomcat peut se relier. Si vous souhaitez mapper plusieurs noms de domaine sur un contenu unique, par exemple, si vous voulez que Tomcat réponde aux adresses et votre_entreprise.com, voire votre_ancienne_entreprise.com, ne configurez pas de conteneurs <Host/> distincts. Dans ce cas, en effet, vous créeriez des threads supplémentaires pour gérer les requêtes entrantes, ce qui risquerait d augmenter considérablement l encombrement de Tomcat sans pour autant offrir de valeur ajoutée. Si vous disposez de plusieurs noms d hôte censés tous servir un contenu identique, utilisez alors un élément <Alias/> au sein du conteneur <Host/> : <Host name=" <Alias>mon_entreprise.com</Alias> <Alias>mon_ancienne_entreprise.com</Alias> <Alias> </Host> L attribut obligatoire appbase définit l emplacement dans lequel cet hôte recherche les applications Web. Dans le fichier de configuration livré avec Tomcat, cet attribut possède la valeur <$CATALINA_HOME>/webapps, qui constitue un choix judicieux de valeur par défaut. (Tous les exemples de ce livre supposent qu il s agit de votre base d application. Si vous décidez de la modifier, vous devrez changer également les exemples.) Le choix de ne pas conserver la valeur par défaut se justifie si vous servez différentes applications Web sur différents hôtes virtuels. En effet, vous pouvez souhaiter qu une application spécifique, telle qu un rapporteur de bogues par exemple, s exécute sur le site Web destiné à vos développeurs, mais ne soit pas accessible depuis votre site public. À l inverse, s ils partagent tous la même base d application, chaque hôte virtuel dispose de sa propre copie de toutes les applications Web chargées en mémoire. Ce qui est peu souhaitable, sauf si vos applications Web fournissent des fonctions d intérêt général. Bien évidemment, vous pouvez opter pour une structure de fichiers différente de celle configurée par défaut, selon des standards locaux ou pour faciliter le développement, par exemple. Vous pourriez ainsi installer un hôte de développement en utilisant votre répertoire de création comme répertoire appbase, bien que l utilisation d un système permettant de déployer les applications dans la base appropriée constitue une solution plus adaptée. Vous pouvez définir un chemin absolu ou relatif. Si vous spécifiez un chemin relatif, il sera considéré comme chemin relatif de <$CATALINA_HOME>.

10 Le fichier server.xml CHAPITRE 7 91 L attribut facultatif classname doit spécifier une classe qui implémente l interface org.apache.catalina.host. La classe par défaut est org.apache.catalina.core.standard- Host. L attribut facultatif autodeploy indique si Tomcat doit automatiquement mettre à jour le serveur actif pour qu il inclue les nouveaux fichiers de l application Web dans le répertoire appbase. La valeur par défaut de cet attribut est true, ce qui se révèle très utile sur les serveurs de développement, puisque, pour la plupart des modifications, aucune opération n est nécessaire pour recharger la servlet. En effet, lorsque l attribut autodeploy est activé, la mise en place d une nouvelle version d un fichier JAR dans le répertoire /WEB-INF/lib entraîne le rechargement des classes. Tomcat recherche par intermittence les fichiers modifiés et, s il en trouve, met à jour les applications Web. Cependant, l activation de cet attribut n est pas toujours conseillée dans un environnement de production. En effet, il est généralement préférable de placer les fichiers et de recharger manuellement l application. En outre, l utilisation de cet attribut ainsi que d autres fonctions de rechargement automatique augmente le temps système de traitement sur le serveur et peut affecter les performances. Le chargement manuel de l application s effectue en redémarrant le serveur ou en utilisant l application de gestion, traitée dans le chapitre 9. En effectuant cette opération de manière explicite, vous détenez davantage de contrôle sur les éléments déployés sur le serveur actif. Cette classe utilise également les attributs suivants : unpackwars Cet attribut facultatif indique si les fichiers WAR contenus dans le répertoire appbase doivent être décompressés au démarrage du serveur. S il possède la valeur true, l hôte vérifie si le répertoire appbase contient des fichiers WAR compressés et les décompresse dans un répertoire portant le même nom que le fichier WAR, sans l extension. Par exemple, le fichier foo.war est décompressé dans le sous-répertoire foo/ du répertoire appbase. Le serveur crée alors un contexte correspondant au nom du répertoire et charge les applications Web qu il contient. Le serveur ne décompresse pas le fichier WAR s il existe déjà un répertoire correspondant. Si vous voulez redéployer une application Web à partir d un fichier WAR, vous devrez supprimer ce répertoire. La valeur par défaut de l attribut unpackwars est true. Par ailleurs, les considérations relatives aux systèmes de production, mentionnées pour l attribut autodeploy, s appliquent également à l attribut unpackwars. livedeploy Cet attribut est facultatif. De fonction similaire à celle de l attribut précédent, il indique si une nouvelle application Web compressée et ajoutée au répertoire appbase doit être automatiquement chargée lorsque le serveur la détecte. Elle possède également la valeur true par défaut, mais celle-ci doit être false sur un serveur de production. deployxml Cet attribut est facultatif. Il indique si un déploiement d exécution basé sur un fichier de contexte XML est autorisé ou non. La version 4 de Tomcat introduit les

11 92 Tomcat par la pratique fichiers de contexte XML qui permettent de conserver les informations relatives au contexte dans un fichier XML distinct (nous y reviendrons dans la section suivante). La valeur par défaut de cet attribut est true. workdir Cet attribut facultatif indique l emplacement dans lequel Tomcat doit écrire les fichiers temporaires, tels que le code source et les servlets compilées qu il génère à partir des pages JSP. Si cet emplacement n est pas précisé, Tomcat crée les répertoires de travail dans le répertoire <$CATALINA_HOME>/work/ et vérifie que chacun possède un nom unique pour éviter les interférences entre différentes applications Web.Vous pouvez modifier cet attribut si vous souhaitez exécuter le serveur Tomcat à partir d un système de fichiers en lecture seule, pour des raisons de sécurité, ou à partir d un volume partagé en lecture seule également. Dans ce cas, vous devez modifier l attribut de sorte qu il pointe vers un répertoire sur lequel Tomcat (c est-à-dire l utilisateur doté des permissions avec lesquelles Tomcat est exécuté) peut écrire. Vous pouvez également écrire sur une autre partition ou volume, tels que /var, pour empêcher les sorties Tomcat de remplir une partition donnée. Toutefois, ce cas de figure est assez rare. errorreportvalveclass Cet attribut est facultatif. Il définit une classe Valve (voir les sections suivantes) à utiliser pour contrôler le format des rapports d erreur fournis par Tomcat. La classe spécifiée doit implémenter l interface org.apache.catalina.valve et la valeur par défaut de cet attribut est org.apache.catalina.valves.errorreportvalve. (Il existe d autres classes Valve concernent le conteneur <Host/> que nous détaillerons par la suite.) debug Cet attribut facultatif fonctionne de la même manière qu avec les autres composants Tomcat. À l instar du conteneur <Engine/>, le conteneur <Host/> peut être configuré également par l ajout des éléments <Realm/>, <Logger/> et <Valve/>. En outre, il existe deux composants supplémentaires configurés en tant qu enfants de l élément <Host/> : les nœuds <Alias/> et les conteneurs <Context/>. Nous avons déjà parlé de l élément <Alias/>. Comme illustré par l exemple fourni, il ne possède aucun attribut et l élément <Host/> peut contenir ou non des éléments <Alias/>. Chaque nœud de ce type contient un nom d hôte supplémentaire à associer avec le conteneur hôte. Le conteneur <Context/> Chaque élément <Host/> peut contenir un ou plusieurs éléments <Context/>. Le conteneur <Context/> est l élément que nous avons le plus souvent rencontré jusqu à présent. Un contexte relie un URI à une application Web. Chaque hôte doit posséder un contexte doté d un chemin d accès vide, comme le spécifie l attribut path. Ce contexte est le contexte par défaut de l hôte et il est utilisé lorsque aucun

12 Le fichier server.xml CHAPITRE 7 93 autre contexte ne correspond. Le contexte par défaut fournit également des informations relatives à la configuration et exploitées par les autres contextes configurés dans l hôte conteneur, à moins que vous ne spécifiiez le contraire. Outre ce contexte par défaut, vous pouvez ajouter autant de contextes que nécessaire. Les chemins d accès aux contextes sont mis en correspondance avec les requêtes entrantes lors de l exécution. Lorsqu une requête arrive, le serveur compare l URI à chaque chemin d accès aux contextes, jusqu à ce qu il trouve le chemin le plus long qui corresponde. La justification de cette règle vous paraîtra plus claire si vous imaginez une application dans laquelle vous souhaitez que les contextes imbriqués soient gérés par des servlets différentes. Par exemple, vous pouvez décider que l URI /intranet soit servi par un contexte donné, et que l URI /intranet/stockplan soit servi par un autre contexte, avec d autres servlets et des exigences différentes en matière d authentification. Dans ce cas de figure, une requête entrante pour /intranet/stockplan/login.jsp sera transmise au deuxième contexte, tandis qu une requête pour /intranet/news/index.jsp sera transmise au premier contexte. En revanche, une requête pour /index.jsp sera transmise au contexte par défaut, puisque aucun des deux contextes ne correspond à l URI. Nous avons déjà configuré des contextes dans le descripteur de déploiement étudié dans le chapitre 6, «Configurer les applications Web» ; comme vous le savez à ce stade, le fichier server.xml ne constitue pas le seul emplacement pour configurer un contexte. En réalité, outre le fichier server.xml et les différents fichiers web.xml, vous pouvez désormais configurer un contexte à partir d un fichier XML distinct. Ce dernier possède la même structure que celle utilisée dans les éléments de contexte contenus dans le fichier server.xml, raison pour laquelle nous en parlons ici. Si vous souhaitez configurer des contextes séparément, il vous suffit d intégrer le conteneur de contexte XML dans un fichier distinct et de le placer à l endroit approprié, tel que le répertoire par défaut <$CATALINA_HOME>/webapps ou selon l attribut appbase défini dans l entrée relative au conteneur <Host/>. Vous pouvez également associer un contexte stocké dans un fichier XML externe avec un hôte spécifié en définissant simplement un attribut appbase distinct pour chaque conteneur <Host/>. L attribut obligatoire path dont nous avons parlé précédemment définit l URI relatif de base d après lequel tous les chemins d accès aux servlets contenues sont établis. Là encore, vous devez disposer d un seul conteneur <Context/> dont la valeur du chemin d accès est une chaîne vide pour former le contexte par défaut. L attribut obligatoire docbase indique l emplacement de l application Web spécifiée dans le contexte. Le chemin d accès défini ici peut-être un chemin vers le répertoire contenant l application Web, ou un chemin comprenant un fichier WAR. Dans ce cas, l application Web est exécutée directement à partir du fichier WAR sans décompresser ce dernier. Si le chemin spécifié est relatif, il est ajouté au chemin défini par l attribut appbase du conteneur <Host/>. Pour le conteneur <Context/>, il n est pas nécessaire de définir l attribut facultatif classname. Dans la plupart des cas, vous pouvez configurer l implémentation par défaut, org.apache.catalina.core.standardcontext, pour effectuer toutes les opérations souhaitées.

13 94 Tomcat par la pratique Si vous choisissez néanmoins de définir une classe, celle-ci doit implémenter l interface org.apache.catalina.context. Comme mentionné précédemment, les attributs facultatifs définis dans le contexte par défaut seront également répercutés dans les autres contextes configurés dans le même conteneur <Host/>. Ces paramètres prévalent sur les attributs correspondants spécifiés dans les autres éléments <Context/>. Vous pouvez renverser ce comportement en attribuant la valeur true à l attribut facultatif override qui possède la valeur false par défaut. L attribut facultatif reloadable indique si le moteur de servlets contrôle ou non les répertoires WEB-INF/lib et WEB-INF/classes dans l attribut docbase configuré et s il recharge ou non les applications Web lorsqu elles sont modifiées. Cet attribut prend par défaut la valeur true, mais il n affecte en rien le chargement du contexte par l application de gestion (voir le chapitre 9 pour plus d informations). L attribut facultatif cookies spécifie si vous autorisez Tomcat à utiliser les cookies pour gérer les sessions. Pour contraindre Tomcat à se fonder uniquement sur la réécriture d URL (URL rewriting) pour des raisons de sécurité ou autres, vous devez attribuer la valeur false à cet attribut (puisque sa valeur par défaut est true). L attribut facultatif crosscontext indique si les objets du contexte peuvent communiquer avec les objets des autres contextes situés sur le même hôte. Plus concrètement, cet attribut indique si les appels vers la méthode ServletContext.getContext() renvoient un contexte valide. Si la valeur de l attribut est false, la méthode renvoie systématiquement la valeur null. À moins de disposer d une bonne raison pour autoriser la communication intercontexte, conservez la valeur par défaut false, pour des raisons de sécurité. L attribut facultatif privileged détermine si les servlets de ce contexte sont autorisées à utiliser des servlets de conteneur spéciales, telles que la servlet de gestion. La valeur par défaut de cet attribut est false. L attribut facultatif wrapperclass définit la classe d enveloppeur que Tomcat doit utiliser pour gérer les servlets contenues dans le contexte. Cette classe est chargée de gérer le cycle de vie des servlets du contexte et de tenir à jour la configuration définie dans le descripteur de déploiement en appelant les méthodes init() et destroy() de la servlet. Elle gère également les communications entre le conteneur et les servlets. Les classes définies dans cet attribut doivent implémenter l interface org.apache.catalina.wrapper ; la valeur par défaut est org.apache.catalina.core.standardwrapper. L attribut facultatif usenaming indique si le moteur de servlets doit créer un contexte JNDI InitialContext pour l application Web. Le contexte InitialContext créé par Tomcat est compatible avec les conventions J2EE. La valeur par défaut de cet attribut est true. Outre ces attributs généraux, la classe par défaut org.apache.catalina.core.standardcontext possède deux autres attributs. Il s agit de l attribut facultatif workdir, qui détermine un répertoire modifiable utilisé par les servlets contenues dans le contexte. Le chemin d accès à ce répertoire de travail est transmis à la servlet sous forme d attribut

14 Le fichier server.xml CHAPITRE 7 95 javax.servlet.context.tempdir dans le contexte ServletContext. Cet attribut est une instance de java.io.file. S il n est pas configuré manuellement, Tomcat affecte un répertoire approprié au sein du répertoire de travail attribué à l hôte. Par défaut, il s agit d un sous-répertoire du répertoire <$CATALINA_HOME>/work. En outre, comme avec les autres composants Tomcat, un attribut facultatif debug est fourni pour configurer une journalisation supplémentaire. À l instar des conteneurs <Engine/> et <Host/>, les conteneurs <Context/> peuvent comprendre les éléments <Realm/>, <Logger/> et <Valve/>. De plus, les éléments <Context/> peuvent inclure les nœuds <Resources/>, <Loader/> et <Manager/>. Les types d éléments que nous n avons pas encore abordés sont traités dans les sections suivantes. L élément <Valve/> Une valve est un composant ajouté à l architecture pipeline du traitement. Elle peut gérer les requêtes et les réponses, limiter l accès, formater les sorties et effectuer d autres tâches encore. Les valves offrent une grande souplesse alliée à une large gamme de fonctionnalités. Au lieu d expliquer la théorie, nous vous proposerons ici plusieurs exemples. Ces composants possèdent un seul attribut obligatoire, l attribut classname qui définit une classe implémentant l interface org.apache.catalina.valve. La valve du fichier journal des accès La valve org.apache.catalina.valves.accesslogvalve permet de formater le contenu des fichiers journaux configurés dans les éléments <Logger/>. Elle peut être utilisée pour mettre en conformité ces fichiers avec les formats Common Log Format ou Combined Log Format, tous deux communément et malheureusement appelés CLF, ou à tout autre format que vous configurez. Les attributs facultatifs directory, prefix et suffix fonctionnent de la même manière que les attributs de l élément <Logger/> (voir la section correspondante, plus haut dans ce chapitre). L attribut facultatif resolvehosts indique si une recherche de nom d hôte doit être effectuée pour chaque adresse IP entrante. Comme nous l avons vu auparavant, l affectation de la valeur true à cet attribut augmente le délai d attente, en particulier pour la première requête, en raison du temps nécessaire à la résolution des noms DNS. Dans un système de production à haute performance, cet attribut doit être défini sur false, à moins que vous souhaitiez, pour une raison quelconque, que ces informations soient consignées en temps réel. Vous pouvez toujours retraiter ces journaux pour ajouter ces informations. L attribut facultatif pattern fournit un modèle de chaîne utilisé pour définir le format en sortie des fichiers journaux. Il se compose de texte littéral et de plusieurs séquences d échappement qui seront remplacés dans la sortie par les informations issues de la requête.

15 96 Tomcat par la pratique Ces séquences d échappement sont les suivantes : %A Définit l adresse IP locale. %a Définit l adresse IP distante. %B Définit le nombre d octets envoyés, sans les en-têtes HTTP. %b Définit le nombre d octets envoyés, sans les en-têtes HTTP, ou prend la valeur - s il n en existe aucun. %H Définit le protocole utilisé dans la requête, tel que HTTP/1.1. %h Définit le nom d hôte distant (ou l adresse IP distante si l attribut resolvehosts est défini sur false). %l Définit le nom utilisateur logique distant issu de identd. Il renvoie toujours la valeur -. %m Définit la méthode de requête (GET, POST, etc.). %p Définit le port local sur lequel cette requête a été reçue. %q Contient toute chaîne de requête envoyée (précédée d un point d interrogation (?) si elle existe). %r Contient la première ligne de la requête dans son intégralité (y compris la méthode et l URI de la requête, telle que GET /index.html). %S Définit l ID de la session utilisateur. %s Définit le code d état HTTP de la réponse (200 pour OK, 404 pour signaler une ressource introuvable, etc.). %t Définit la date et l heure, exprimées au format Common Log Format. %U Définit le chemin d accès à l URL requise. %u Si l authentification HTTP est utilisée, définit l utilisateur authentifié ou renvoie la valeur "-" s il n en existe aucun. %v Définit le nom du serveur local. %{<header>} Indique que l en-tête correspondant à <header> doit être inclus dans la sortie. %{<header>}i Indique que l en-tête correspondant à <header> doit être inclus dans la sortie, sans tenir compte de la casse. Il existe deux noms de modèles particuliers pour les deux formats CLR. Le modèle common définit le format de journalisation usuel, qui correspond à %h %l %u %t "%r" %s %b. Le modèle combined ajoute les valeurs des en-têtes Referer et User-Agent, et correspond au modèle * %h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i". La valeur par défaut est common.

16 Le fichier server.xml CHAPITRE 7 97 Les filtres d hôte distant et d adresse distante Les filtres d hôte distant et d adresse distante, respectivement org.apache.catalina.valves.remotehostvalve et org.apache.catalina.valves.remoteaddrvalve, permettent de restreindre l accès à certains hôtes, d après leur nom de domaine ou leur adresse IP. Leur fonctionnement est similaire, à ceci près qu ils établissent une correspondance sur la base soit des noms d hôte, soit des adresses IP. Ces deux filtres possèdent chacun un attribut allow et deny, tous deux facultatifs et utilisés pour restreindre l accès. Chacun accepte, comme critères de correspondance, une liste d expressions rationnelles séparées par une virgule. Si les critères de l attribut allow sont spécifiés, l accès est autorisé uniquement pour les hôtes qui correspondent à une ou plusieurs expressions rationnelles définies dans le paramètre. Tout utilisateur provenant d un hôte ne correspondant pas aux critères reçoit du serveur la réponse 403 affichant un message interdisant l accès. En revanche, si l attribut deny est employé, tout utilisateur provenant d un hôte qui ne correspond pas aux expressions régulières obtient l accès, et l utilisateur issu d un hôte correspondant aux critères de l attribut deny reçoit une réponse 403. Si les deux attributs sont définis, l attribut deny est contrôlé en premier et l utilisateur qui ne répond pas à ses critères est transmis au filtre accept. Enfin, les utilisateurs provenant d un hôte correspondant aux critères de ces deux attributs sont autorisés à consulter le contenu. Valve d affichage de requête La valve d affichage de requête, org.apache.catalina.valves.requestdumpervalve, s avère très utile pour le déboguage des interactions clients inattendues. En effet, elle consigne le contenu de chaque requête entrante dans le fichier journal configuré. Cette fonction se révèle très efficace lorsque vous travaillez avec des clients personnalisés ou lorsque vous rencontrez des difficultés avec l un ou plusieurs d entre eux, puisque la valve permet de connaître le contenu envoyé au serveur. Elle ne possède pas d attribut en dehors de l attribut obligatoire classname. Valve de session unique La valve de session unique est utilisée dans le conteneur <Host/> pour partager les identités de realms entre les différentes applications. Nous reviendrons sur ce sujet dans le chapitre 8, «Gérer l authentification avec les realms». Autres valves Il existe d autres valves que celles présentées dans ce chapitre. Certaines appartiennent au projet Apache, d autres non. Bien évidemment, vous pouvez toujours écrire vos propres valves. Nous allons en présenter une brièvement, pour vous donner quelques idées. Les valves non incluses dans la distribution principale doivent être ajoutées au répertoire <$CATALINA_

17 98 Tomcat par la pratique HOME>/server/lib si elles sont compressées sous forme de fichier JAR; s il s agit de classes, au répertoire <$CATALINA_HOME>/server/classes, dans les sous-répertoires adaptés à leur hiérarchie de paquetage. La valve du fichier journal des accès JDBC La valve org.apache.catalina.valves.jdbcaccesslogvalve est un bon exemple de valve d extension. Elle permet d enregistrer la sortie dans une base de données et non dans un système de fichiers. Ses attributs sont identiques à ceux de la classe logger, et elle fournit deux attributs supplémentaires permettant de définir une classe pour le pilote JDBC et l URL JDBC désignant la base de données contenant le fichier journal. Vous trouverez davantage d informations sur ce sujet dans la documentation JavaDoc de Tomcat. Si vous utilisez cette valve, n oubliez pas de placer le fichier JAR contenant le pilote JDBC dans le répertoire <$CATALINA_ HOME>/server/lib ou <$CATALINA_HOME>/common/lib. L élément <Resources/> L élément <Resources/> permet de définir les autres ressources disponibles pour l application Web spécifiée dans le conteneur <Context/> ; elle permet à la servlet d accéder aux autres ressources que celles stockées dans un système de fichiers, qu il s agisse de ressources contenues dans un fichier JAR ou WAR, de données issues d une base de données, des éléments d un répertoire JNDI ou autre. Si un élément <Resources/> n est pas spécifié pour un conteneur <Context/> donné, une instance par défaut basée sur le système de fichiers est créée pour définir le contexte. Notez que les ressources contenues dans des dépôts de données non basés sur des systèmes de fichiers doivent demeurer accessibles à l aide des méthodes du contexte ServletContext. Le moteur de servlets n intercepte pas les appels qui opèrent sur les fichiers pour les traduire automatiquement ; en revanche, le contexte ServletContext renvoie un contexte initial JNDI et vous pouvez utiliser ses méthodes pour rechercher et extraire les objets stockés dans les dépôts rendus disponibles par le nœud <Resources/>. Par conséquent, l attribut facultatif classname doit définir une classe implémentant l interface javax.naming.directory.dircontext. Il s agit du seul attribut de portée globale sur toutes les implémentations. Notez que le framework Tomcat propose certaines classes de base permettant de simplifier l implémentation des classes à configurer dans l élément <Resources/>. Il est conseillé de baser vos propres classes sur l interface org.apache.naming.resources. BaseDirContext et d utiliser les objets de org.apache.naming.resources pour les types de renvoi. L interopérabilité et les performances n en seront que meilleures. La valeur par défaut de cet attribut est org.apache.naming.resources.filedircontext. Nous traiterons des attributs supplémentaires fournis avec cette classe dans la suite de ce chapitre. L attribut facultatif cached indique si l implémentation doit utiliser la mise en cache. La valeur par défaut est true.

18 Le fichier server.xml CHAPITRE 7 99 L attribut facultatif casesensitive est utilisé sur les systèmes d exploitation insensibles à la casse, tels que Microsoft Windows, pour déterminer si la sensibilité à la casse doit être prise en compte lors de la recherche d objets. La valeur par défaut est true. L attribut facultatif docbase définit le répertoire racine du système de fichiers dans lequel se trouvent les ressources nommées. Il possède la même syntaxe et suit les mêmes règles que l attribut docbase d un contexte ; de plus, il est élaboré à partir de la base de document du contexte conteneur si un chemin relatif est utilisé. L élément <Loader/> L élément <Loader/> permet de configurer un chargeur de classes différent de celui fourni par défaut avec Tomcat, ou d en contraindre l action. Lorsqu il est spécifié, cet élément doit apparaître comme enfant du conteneur <Context/> ; dans le cas contraire, une instance de l implémentation du chargeur de classes par défaut, org.apache.catalina.loader.webapploader, est utilisée. Dans les environnements où les problématiques de sécurité sont importantes, nous vous conseillons de configurer au moins les attributs delegate et reloadable, que nous allons traiter dans un instant. L attribut facultatif classname doit définir une classe qui implémente l interface org.apache.catalina.loader interface. Utilisez l attribut facultatif delegate si vous souhaitez que le chargeur de classes suive le standard de délégation Java 2 et tente de charger les classes à partir des chargeurs parents avant d effectuer une recherche dans l application Web elle-même. Cette procédure permet d éviter que les classes contenues dans l application Web ne prévalent sur le comportement des classes portant le même nom dans l environnement d exécution et, par conséquent, offre davantage de sécurité. Si cet attribut possède la valeur par défaut false, le chargeur de classes opère d abord depuis l application Web avant de demander aux chargeurs parents de rechercher les classes ou les ressources requises. Cet attribut offre donc davantage de souplesse aux applications Web et simplifie la configuration ; cependant, si vous visez d abord la sécurité, comme il se doit dans un environnement de production, vous devez affecter la valeur true à l attribut delegate, surtout si vous autorisez un code peu sécurisé à s exécuter sur le serveur. Il existe d autres moyens de contraindre l accès aux ressources, mais à moins que vous ne deviez passer outre le comportement des classes accessibles de manière globale, il est inutile de laisser la valeur false à cet attribut. L attribut facultatif reloadable, à l instar de l attribut reloadable du conteneur <Context/> étudié plus haut, indique si le moteur de servlets contrôle les répertoires WEB-INF/lib et WEB- INF/classes dans l attribut docbase configuré et s il recharge ou non les applications Web lorsqu elles sont modifiées. Là encore, ce paramètre n affecte en rien le chargement du contexte par l application de gestion. L attribut reloadable prend par défaut la valeur true.

19 100 Tomcat par la pratique INFO Toute valeur définie dans le contexte parent prévaut sur l attribut reloadable. Outre les attributs standards, la classe org.apache.catalina.loader.webapploader prend en charge les attributs suivants : checkinterval Cet attribut facultatif définit la fréquence, en secondes, à laquelle Tomcat vérifie si les bibliothèques des répertoires WEB-INF/lib/ et WEB-INF/classes/ ont été modifiées. Il est ignoré si l attribut reloadable est défini sur false. La valeur par défaut de l attribut checkinterval est 15 secondes. loaderclass Cet attribut facultatif permet de définir toute classe implémentant l interface java.lang.classloader que Tomcat doit utiliser pour effectuer le chargement des classes. Ainsi, il est inutile d implémenter votre propre classe d enveloppeur pour prendre en charge un autre chargeur de classes que vous souhaiteriez utiliser. La valeur par défaut de cet attribut est org.apache.catalina.loader.webappclassloader. workdir Cet attribut facultatif fonctionne de la même manière que l attribut workdir du conteneur <Context/>. debug Cet attribut facultatif fonctionne de la même manière que dans les autres classes principales. L élément <Manager/> L élément <Manager/> permet de configurer le gestionnaire de session utilisé dans le contexte conteneur. Ce gestionnaire est chargé de créer et de gérer les objets de session ainsi que la clé utilisée pour rechercher la session. L élément <Manager/> doit être imbriqué dans un conteneur <Context/> s il est utilisé. À l instar des nœuds <Loader/> et <Resources/>, une seule instance de cet élément doit exister dans un conteneur <Context/>. S il est omis, l implémentation par défaut org.apache.catalina.session.standardmanager est utilisée. Une deuxième implémentation digne d intérêt est fournie avec Tomcat : la classe org.apache.catalina.session.persistentmanager. Celle-ci stocke des informations relatives à la session sur le disque et permet aux sessions de survivre à un redémarrage de Tomcat. Notez qu à l heure de la rédaction de cet ouvrage, cette classe n a pas été testée entièrement. Si vous souhaitez toutefois l utiliser dans un environnement de production, prévoyez de la tester sérieusement et d effectuer quelques modifications. Si des changements s avèrent nécessaires ou si vous découvrez des limitations lors du test de cette classe ou des autres composants, nous vous encourageons vivement à partager vos découvertes avec la communauté Tomcat. Toutes les implémentations de cette classe partagent les attributs suivants :

20 Le fichier server.xml CHAPITRE classname Cet attribut facultatif doit correspondre au nom d une classe implémentant l interface org.apache.catalina.manager. La valeur par défaut est org.apache.catalina.session.standardmanager. distributable Cet attribut facultatif détermine si le gestionnaire doit se conformer aux normes de la spécification sur les servlets relatives aux sessions distribuables. Cette notion est fondamentale si vous utilisez Tomcat dans un environnement en clusters et si vous partagez un état de session dans un pool d instances Tomcat. Cela impose une contrainte principale pour l objet de session qui doit être sérialisable, c est-à-dire qu il doit implémenter l interface java.io.serializable qui requiert à son tour que tous les objets qu elle contient doivent être sérialisables. Si l attribut distributable est défini sur false (valeur par défaut), Tomcat autorise alors la création de sessions non sérialisables. S il n est pas défini ici, cet attribut est hérité du descripteur de déploiement de l application Web via l élément <distributable/>. maxinactiveinterval Cet attribut facultatif définit la durée d inactivité des sessions avant que leur délai n expire. À l instar de l attribut distributable, vous pouvez définir l attribut maxinactiveinterval dans le descripteur de déploiement de l application Web, et dans ce cas, dans l élément <session-timeout/>. La valeur par défaut est 60 minutes. L implémentation standard org.apache.catalina.session.standardmanager possède les attributs supplémentaires suivants : checkinterval Cet attribut facultatif définit en secondes la fréquence de vérification de l expiration des sessions. La valeur par défaut est 60. maxactivesessions Cet attribut facultatif détermine le nombre maximal de sessions actives que le gestionnaire peut créer. Si la valeur attribuée est la valeur par défaut -1, le gestionnaire ne limite pas le nombre de sessions. algorithm Cet attribut facultatif définit l algorithme que doit utiliser Tomcat pour générer une clé de session. La valeur spécifiée ici doit être prise en charge par java.security.messagedigest. Il peut s agir de MD5, MD2, et SHA-1, et vous pouvez charger des algorithmes supplémentaires en ajoutant et en chargeant la bibliothèque tiers appropriée. La valeur par défaut de cet attribut est MD5. randomclass Cet attribut facultatif détermine la classe que doit utiliser Tomcat pour générer les nombres aléatoires nécessaires à l initialisation de l algorithme concis. Cette classe doit implémenter l interface java.util.random et la valeur par défaut est java.security.securerandom. entropy Cet attribut facultatif définit une chaîne d amorçage utilisée pour initialiser le générateur de nombres aléatoires spécifiés dans l attribut randomclass. Si aucune chaîne n est définie, Tomcat tente de générer une valeur d amorçage utile, mais dans les environnements privilégiant la sécurité, il est préférable d attribuer une très longue chaîne à cet attribut. La valeur par défaut consiste à autoriser Tomcat à en générer une.