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
 
             
Déploiement d'une application web sous Tomcat

 

 

Introduction

Le déploiement d'une application web sur un serveur d'applications signifie en quelque sorte son installation. Il s'agit en fait de rendre l'application accessible au serveur et de la lui présenter (qu'il sache l'exécuter et lui passer les requêtes la concernant). Nous allons maintenant voir les différents moyens que nous offre Tomcat pour déployer une application.

 

Installer un fichier WAR

Tomcat, comme tout moteur de servlet (cela respecte les spécifications) accepte une archive WAR comme application web. Celle-ci devra bien sûr respecter la structure d'une webapp. Ce fichier doit être déposé dans le répertoire appBase de l'Host sur lequel l'application est installée. En règle générale, ce répertoire est TOMCAT_HOME/webapps. Au prochain démarrage de Tomcat, il détectera le nouveau fichier WAR, et créera automatiquement un Context correspondant dans le fichier de configuration. L'application sera dès lors accessible. De plus, en règle générale (sauf configuration contraire), le WAR sera déployé, c'est-à-dire que l'arborescence de fichiers et répertoires qu'il contient sera décompactée dans un répertoire portant le même nom que le WAR.

 

Installer l'application décompactée

Nous avons vu qu'un WAR est une archive contenant l'arborescence d'une application web. Tomcat accepte également que l'on dépose directement l'application décompactée dans le répertoire appBase de l'Host sur lequel l'application est installée. Notons que cela n'est pas un comportement standard, et qu'à ce titre, tous les serveurs d'application Java ne permettent pas forcément cela.

 

Créer manuellement le contexte

Il est également possible de créer soi-même un élément Context représentant l'application dans le fichier de configuration du serveur, TOMCAT_HOME/conf/server.xml. Cela permet de spécifier un répertoire racine pour l'application différent d'un sous-répertoire du répertoire appBase de l'Host sur lequel l'application est installée. En effet, Tomcat ne surveille que ce répertoire. Donc, si vous avez copié votre application dans "c:/monappli", il vous faudra créer manuellement le contexte.

 

Utiliser le "Manager" de Tomcat

 

Tomcat propose une application nommée "Manager", et déployée par défaut sous "http://server:port/manager/html". Elle permet d'effectuer différentes tâches d'administration sur les applications web du serveur, notamment les démarrer ou les arrêter. En outre, elle autorise le déploiement d'une nouvelle application web à partir d'une archive WAR, déjà présente sur le serveur ou uploadée depuis une machine distante. L'autre force de ce "Manager" est qu'il n'oblige pas à redémarrer le serveur après un déploiement.

 

Utiliser un fichier de configuration de contexte

Dans le répertoire appBase d'un Host, on peut déposer, outre les WAR ou applications décompactées, des fichiers de configuration de contexte. Ce sont des fichiers XML contenant comme élément de base un Context, et tous les sous-éléments que l'on peut souhaiter. Il s'agit en fait ici de délocaliser les informations de contexte d'une application. Le format est exactement le même que si on configurait ce Context dans le fichier de configuration du serveur. Cela s'avère intéressant, car ces fichiers peuvent être pris en compte (et les applications correspondantes déployées) sans que le serveur redémarre. Alors que toute modification du fichier server.xml nécessite un redémarrage de Tomcat pour être effective.