Java & le web
x Le web dynamique
x Java & le web

Intro à Tomcat
x Serveur d'applications
x Présentation Tomcat
x Installation
x Arborescence

Configuration
x Introduction
x Server
x Service
x Engine
x Host
x Context
x DefaultContext
x Logger
x Loader
x Realm
x Valve

Connecteurs
x Balise Connector
x Coyote HTTP/1.1

Sécurisation accès
x La balise Realm
x Memory Based
x JDBC Database
x Protéger ressources
x Cryptage password

Les Valve
x La balise Valve
x Access Log
x Single Sign-On

Fonctionnalités
x Déploiement auto.
x Class loaders

Eclipse & Tomcat
x Plug-in pour Eclipse
x Projet Tomcat
x Debugger des JSP

Créer une appli web
x Présentation
x Architecture
x Fichier web.xml
x Déploiement

Tomcat 5
x Nouveautés

Tomcat's Corner
x Crédits
x Liens
 
             
Les nouveautés de Tomcat 5

 

Ce site a été conçu en référence à Tomcat 4. Néanmoins, pendant sa conception, la version 5 de Tomcat est sortie. Si les informations contenues au fil des pages restent exactes (sauf mention contraire, erreur ou omission), la nouvelle version du serveur est riche de nouveautés. Cette page présente donc les fondements de Tomcat 5, et les nouvelles fonctionnalités qu'il apporte.

 

Introduction

Si le numéro de version maître de Tomcat est passé de 4 à 5, c'est parce que la nouvelle version du serveur répond aux nouvelles spécifications Servlet et JSP. Tomcat 4 suivait les spécifications Servlet 2.3 et JSP 1.2. La version 5 répond aux spécifications Servlet 2.4 et JSP 2.0.

Les spécifications Servlet 2.4 sont une évolution très légère des précédentes (2.3). C'est intéressant, car les applications tournant sous Tomcat 4 n'auront ainsi pas à être modifiées pour fonctionner sous Tomcat 5, à de très rares mais possibles exceptions près, à gérer au cas par cas. Les apports des nouvelles specs JSP sont beaucoup plus importants. Mais là encore, la compatibilité descendante est assurée. Jusqu'ici tout va bien...

 

Fichiers de configuration

Le fichier de configuration du serveur, server.xml, voit sa syntaxe légèrement modifiée dans Tomcat 5. Si, grossièrement, la syntaxe reste la même, certains éléments ont été refondus. On ne pourra donc pas se contenter de recopier notre server.xml de Tomcat 4. Il faudra vérifier que les attributs utilisés dans celui-ci sont encore valables dans la configuration de Tomcat 5. Les plus grosses modifications ont trait aux connecteurs, qui ont été redéveloppés (un grand nombre d'attributs diffèrent), les Host (incompatibles avec ceux de Tomcat 4) et les Context (qui bénéficient principalement de nouvelles fonctionnalités, donc de nouveaux attributs). Pour effectuer la migration, un travail s'impose donc sur cette configuration. Travail qui peut s'avérer long, si de nombreuses personnalisations avaient été effectuées dans la configuration de Tomcat 4.

 

Amélioration du déploiement automatique d'applications

Nous avons parlé des fichiers de configuration de contextes. Ils permettent de définir un Context (une application web) en dehors du fichier de configuration du serveur. Avantage : ces fichiers peuvent être pris en compte sans redémarrage du serveur. Inconvénient : le contrôle de l'Host sur lequel ces applications sont déployées est moins fin. Tomcat 5 règle le problème, en déménageant ces fichiers de configuration de contextes. Chaque Engine, puis chaque Host, se voit affecter un répertoire dans TOMCAT_HOME/conf. Et ces petits fichiers doivent être déposés dans ces répertoires. Les répertoires sont créés selon la syntaxe suivante : TOMCAT_HOME/conf/nom_de_Engine/nom_de_Host. Donc, si vous avez configuré un Engine nommé StandAlone et un Host nommé localhost, les fichiers de configuration de contextes placés à n'importe quel moment dans le répertoire TOMCAT_HOME/conf/StandAlone/localhost permettront le déploiement automatique de l'application qu'ils décrivent.

 

Déployeur autonome

Tomcat 5 propose en téléchargement un déployeur autonome d'applications web (un composant détaché de Tomcat). Il s'agit en fait d'un script Ant orienté applications web, avec de nombreuses tâches personnalisées. Il permet notamment de compiler l'application (y compris les JSP), de valider la syntaxe XML du descripteur de déploiement, de déployer l'application dans un Tomcat, la démarrer, l'arrêter... Il est ainsi aisé de vérifier qu'une application se compile correctement, et fonctionne, avant de la lancer en production.

 

Optimisation mémoire

En Java, la suppression des objets inutilisés (vers lesquels plus aucune référence ne pointe) n'est pas le fait du développeur. C'est le garbage collector qui s'en occupe. Dans le cas d'un serveur, de très nombreux objets sont régulièrement instanciés, dans de nombreuses situations, et peu réutilisés. Le "problème" (qui n'en est un que dans des situations de charge importante) est que, lorsque le garbage collector tourne pour récupérer l'espoire mémoire des objets à détruire, le reste de la JVM (machine virtuelle Java) doit s'interrompre. Donc, toutes les requêtes en cours de traitement sont suspendues. Pendant une durée minime, certes, mais qui peut ralentir le serveur dans certains cas. Tomcat 5 propose de nombreuses optimisations côté mémoire, notamment en termes de réutilisation d'objets. Plus d'objets réutilisés, c'est moins de "déchets" (objets à détruire), donc moins de "ramassage des déchets" (garbage collection).

Toujours en vue de réduire les instanciations inutiles d'objets, Tomcat 5 crée des pools pour les taglibs. Les taglibs sont des librairies de balises JSP personnalisées. Comme ces objets peuvent être réutilisés d'une requête à l'autre, un pool est créé. Les objets, après utilisation, sont purgés des éléments spécifiques à la requête venant d'être traitée, puis remis dans le pool en attendant une autre sollicitation.

 

Répartition de charge

Tomcat 5.0 propose un répartiteur de charge (load balancing) "logiciel", puisqu'il s'agit d'une application web nommée "Balancer", et située dans le répertoire TOMCAT_HOME/webapps/balancer. Il permet de répartir la charge d'une application entre plusieurs serveurs Tomcat. Puisqu'il s'agit de load balancing logiciel, la répartition s'opère par redirections HTTP. Cette fonctionnalité est toute neuve (dans Tomcat s'entend), et cette application n'est pas en mesure de concurrencer une quelconque solution de load balancing commerciale. Mais elle a le mérite d'exister et de permettre d'effectuer de la répartition de charge en utilisant uniquement Tomcat. Qui présente de nombreux avantages, notamment celui d'être gratuit...