Installation et configuration de Tomcat v4 sous Linux

Stéphane RAULT -

Version 0.3 - Dernière mise à jour le 13 Février 2004

Version originale http://www.espace-groupware.com/apache/jakarta/tomcat/index.html

Rédiger une documentation est toujours un travail long et difficile. Vous trouverez sans aucun doute des fautes d'orthographes et peut être même techniques, n'hésitez surtout pas à me les signaler.

Les critiques, suggestions et remerciements sont les bienvenues.

Cette documentation peut être reproduite entièrement ou partiellement mais je vous demanderais juste de me le signaler en m'envoyant un message.


Chaque technologies, languages de développement et concepts apporte son lot de termes spécifiques qu'ils vous faut apprendre avant d'entrevoir la lumière.

NE VOUS DECOURAGEZ PAS, faites-vous violence et appréciez ce moment de grâce où tout devient clair.


Table des matières

Introduction

A part, quelques particularités liés à Unix, cette documentation est également valable pour Tomcat en environnement Windows.

Connaissances requises pour l'exploitation de Tomcat

Un peu de théorie !

Qu'est-ce que Java ?

Java est avant tout une application. Comme toute application Java s'exécute à l'intérieur d'un système d'exploitation.

Java est également un environnement d'exécution, une sorte de sous-système que l'on appelle "La machine virtuelle", dans laquelle peuvent s'exécuter des programmes écrit en Java.

Java est aussi un language de développement objet. Le code java est compilé et sa syntaxe ressemble de très près au C++.

Le fait que le code Java s'exécute dans la machine virtuelle, permet de ne programmer qu'une seule fois et d'exécuter n'importe où. Java est donc très portable.

On ne peut résumer Java en quelques lignes, mais les explications précédentes permettent de situer Java pour des personnes n'ayant peut être aucune notion de programmation dans des languages Objet comme Java.

Vous pourriez passez une vie entière à découvrir ce que Java sait faire mais dans ce document nous nous contenterons de découvrir comment l'utiliser pour exploiter un serveur Tomcat.


Un petit programme Java tout simple

Création d'un programme Java nommé Hello, dont le seul but est d'afficher le mot "Bonjour !" à l'écran

# Fichier Hello.java

public class Hello {

	public static void main( String[] args ) {
		System.out.println("Bonjour !");
	}
}

Compilation du programme avec le compilateur "javac" :

[root@linux /]$ javac Hello.java

Le compilateur vient de créer un fichier Hello.class, c'est le Hello.java après compilation

Exécution du programme Hello :

[root@linux /]$ java Hello
Bonjour !

Vous venez de voir la conception d'un programme Java dans sa forme la plus simple.


Qu'est-ce qu'une API ?

Imaginez que vous mettiez au point un logiciel de sauvegarde ultra-puissant et que vous vouliez le mettre à disposition du monde entier.

En résumant un peu, un logiciel de sauvegarde sera composé de :

Vous mettez donc vos sources à disposition sur Internet pour que d'autres l'utilise et que des développeurs apportent leurs contributions pour l'améliorer.

Si vous avez respecté les principes de la Programmation Orientée Objet (POO), votre application est modulaire et la modification d'un module ne devrait pas remettre en cause l'application entière.

Ecrivons de façon TRES sommaire, le programme principal :

public class SuperSauvegarde {

	public static boolean lance_la_sauvegarde(){
		compresse();
		verifie_integrite();
		journalise();
            System.out.println("Super, j'ai tout sauvegardé !");
	}

	private static void compresse() {
		applique_mon_super_algorithme();
	}

	private static void verifie_integrite() {
		applique_ma_super_verification();
	}

	private static void journalise() {
		ecrit_dans_les_logs();
	}
}

Exécutons ce magnifique programme :

[root@linux /]$ java SuperSauvegarde.lance_la_sauvegarde()
Super, j'ai tout sauvegardé !

OUI mais !

Le problème, c'est que avez tout codé en dur (comme on dit chez les développeurs). Vous avez passé des semaines à écrire un programme qu'il faut reprendre à zéro pour satisfaire toute les demandes. De plus ces trois développeurs n'ont pas les mêmes besoins.

C'est le moment de sortir l'API mais ne cherchez pas dans votre tiroir, j'ai déja regardé elle ne s'y trouve pas.

L'A.P.I. (Application Programming Interface) apporte une couche d'abstraction qui va vous aider à sortir de ces problèmes.

L'API n'est pas une application mais une façon de programmer. C'est une interface entre votre logiciel et le monde extérieur.

Révisons votre logiciel de sauvegarde en l'organisant de façon différente :

# Définition d'une interface pour l'algorithme de compression :
public interface I_Compresseur {
	public void compresse();
}

# Définition d'une interface pour la vérification d'intégrité :
public interface I_Integrite {
	public void verifie_integrite();
}

# Définition d'une interface pour la journalisation :
public interface I_Journalise {
	public void journalise();
}

Mine de rien, nous venons de définir votre API, c'est le seul code source dont aura besoin un autre développeur pour étendre votre application sans tout remettre en cause.

Maintenant, faisont ce que feront ces programmeurs pour utiliser votre logiciel, créont une première implémentation de cette API :

# Fournir une implémentation pour l'interface de compression :
public class Compresseur implements I_Compresseur {
	public void compresse() {
		/* Ecrivez ici votre super algorithme de compression */
	}
}

# Fournir une implémentation pour l'interface de vérification d'intégrité :
public class Integrite implements I_Integrite {
	public void verifie_integrite() {
		/* Ecrivez ici le code de vérification d'intégrité */
	}
}

# Fournir une implémentation pour l'interface de journalisation :
public class Journalise implements I_Journalise {
	public void journalise(){
		/* Ecrivez ici le code de journalisation */
	}
}

Nous venons maintenant, de créer notre première implémentation de l'API pour votre logiciel de sauvegarde.

Il faut maintenant réviser le programme principal pour qu'il profite de l'API :

# Fichier SuperSauvegarde.java :
public class SuperSauvegarde {

	public static boolean lance_la_sauvegarde( I_Compresseur cmp, I_Integrite integ, I_Journalise journ ){
		cmp.compresse();
		integ.verifie_integrite();
		journ.journalise();
	}
}

# Fichier UtiliseSuperSauvegarde.java
public class UtiliseSuperSauvegarde {

	public static void main( String[] args) {
	
		/* Création d'une instance de l'objet Compresseur */
		Compresseur mon_compresseur = new Compresseur();

		/* Création d'une instance de l'objet Integrite */
		Integrite mon_integrite = new Integrite();

		/* Création d'une instance de l'objet Journalise */
		Journalise mon_journal = new Journalise();

		/* Exécution finale en fournissant un compresseur, un vérificateur et une journalisation */
		SuperSauvegarde.lance_la_sauvegarde( mon_compresseur, mon_integrite, mon_journal );
	}	

}

Que feront des développeurs extérieurs pour satisfaires leurs besoins (non pas ces besoins là) :


Un programme Java utilisant une API Tomcat

Tomcat comme la plupart des applications du groupe Apache, est une très belle leçon de programmation et d'utilisation du sujet que nous venons d'aborder : l'API.

Explication sur l'exemple suivant :

Tomcat comme tous bon serveur de servlet, fournit un système d'authentification vous permettant d'utiliser un annuaire LDAP, SQL ou un fichier xml comme référentiel.

Le problème est que le seul annuaire dont je dispose pour authentifier mes utilisateurs, est un serveur Lotus Domino et que Tomcat ne fournit aucun connecteur pour Lotus.

En vérité, je pourrais utiliser le connecteur LDAP puisque Lotus Domino est compatible avec ce protocole. Mais comme je suis tétu et que je veux refaire le monde, je vais tous de même développer une extension spécifique.

Tomcat met à la disposition des développeurs une grande quantité d'interface, permettant ainsi d'étendre ce produit à volonté tout en garantissant une certaine homogénéité des développements et sans remettre en cause le serveur lui-même.

Pour étendre les fonctions d'authentification, je vais donc créer une implémentation de l'interface "Realm".

En regardant bien la documentation et les sources de cette interface, je m'aperçois qu'il faut réécrire énormément de fonctions alors que la seule chose qui m'interressent est d'utiliser mon annuaire Domino pour l'authentification.

Donc je vais étendre la classe "RealmBase" qui fournit une première implémentation de l'interface "Realm".

# Fichier DominoRealm.java

/* Importation des classes java de Lotus Domino */
import lotus.domino.*;

public class DominoRealm extends RealmBase {

      /* Surcharge de la méthode d'authentification appellée par Tomcat lors 
      de l'accès à une page protégée */

      public Principal authenticate(String login, String password) {

           /* Ecriture de mon code spécifique à Domino */ 

           /* Recherche d'un utilisateur pour ce login dans une base Lotus */

           /* Vérification du mot de passe */	

           /* Authentification terminée */	
      }

}

Voilà, je dispose maintenant d'une extension à Tomcat, me permettant d'être authentifié auprès d'un annuaire Lotus Domino. Il ne reste plus qu'à installer cette extension mais nous verrons cela dans les chapitres suivants.


Qu'est-ce qu'une spécification ?

Vous voulez vraiment le savoir ? D'accord mais alors dans les grandes lignes :

Voyons la spécification Servlet et ce que demande Sun ou plutôt le JCP (Java Community Process) :

C'est vraiment un résumé qui montre dans l'ensemble, que respecter une spécification, veut simplement dire, être en conformité avec les directives que cette dernière impose.

Vous pouvez développer votre propre serveur de Servlet du moment que vous respectez les spécifications.


Qu'est-ce qu'un(e) SERVLET ?

Vous connaissez peut être les APPLETS, qui se télécharge et s'exécutent dans un navigateur Internet.

Pour être plus précis, les applets s'exécutent dans la machine virtuelle Java qui elle même s'installe dans votre navigateur internet.

Les servlets, eux, s'exécutent sur le serveur et permettent d'éviter le téléchargement de classes Java ainsi que les problèmes d'incompatibilités avec les différentes machines virtuelles et navigateurs sur les postes clients.

Le rôle principal d'un Servlet, est de renvoyer du contenu HTML de façon dynamique comme le font PHP, CGI, SHTML ou n'importe quelles technologies s'exécutant sur le serveur.

L'utilisation la plus fréquente d'un Servlet est la validation et l'enregistrement d'un formulaire.


Un exemple de servlet

Si vous avez lû le chapitre réservé au API, vous verrez que écrire un servlet consiste simplement à utiliser une classe Java qui implémente une des interfaces de l'API Servlet :

import java.io.*;

/* Importation des classes de l'API servlet */
import javax.servlet.*;
import javax.servlet.http.*;

/* Définition du servlet Bonjour */
public class Bonjour extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws IOException, ServletException
    {
        response.setContentType("text/plain");
        PrintWriter out = response.getWriter();
        out.println("Bonjour !");
    }
}

Pour utiliser cette servlet, c'est très simple :

Dans un navigateur internet, il suffirait de saisir : http://www.monsite.com/appli/servlet/Bonjour

Vous verriez s'afficher un simple "Bonjour !"

Conclusion sur les servlets :


Qu'est-ce qu'un(e) JSP ?

Les JSP (Java Server Page), sont une extension des Servlets.

Vous avez remarqué que dans le Servlet précédent, nous n'avons inclus que du code Java

Dans une page JSP, nous pouvons écrire du code Java et HTML en même temps.

La compilation du code Java est réalisé par le serveur Tomcat dès la première demande d'accès à cette page.


Un exemple de JSP

Transformation du servlet précédent en page JSP :

/* Page bonjour.jsp : écrite avec n'importe quel éditeur de texte */

<%=out.println("Bonjour !")%>

/* Ou ce qui revient au même */

Bonjour !

L'exemple est volontairement simplifié, mais sachez que dès la première utilisation de cette page, Tomcat va transformer cette-ci en Servlet dans un fichier Java compilé.


Qu'est qu'une Application WEB ?

C'est une terminologie que vous retrouvez souvent dans le monde des serveurs de servlets. Il s'agit simplement d'un ensemble de fichiers (Jsp, html, images, class, jar, etc..) rassemblés dans une structure arborescente normalisée.

C'est aussi une application qui s'exécutera dans son propre contexte et s'installera à l'intérieur d'un serveur de servlet comme Tomcat

La finalité de Tomcat est de gérer des applications WEB.

L'intégration d'une application Java dans le système d'exploitation

L'objectif de cette rubrique est de bien expliquer comment une application sous Tomcat va s'intégrer au système d'exploitation de la machine.

Votre fournisseur vient de livrer la dernière version d'une application WEB qui peut normalement s'installer sur n'importe quel serveur de Servlet, dans notre cas Tomcat.

Remarque : Pour commencer, si vous pensiez que vous n'auriez qu'à cliquer sur un exécutable ou lancer une commande pour installer cette application, vous n'êtes pas au bout de votre peine.

L'application peut être livrée sous la forme d'une archive ".war" (lisible avec Winzip ou unzip) ou bien sous la forme d'un ensemble de fichiers et répertoires respectant une certaine convention.

Un chapitre de ce document est entièrement dédié aux déploiements d'application Web, ce qu'il faut comprendre ici, c'est dans quel contexte je peux utiliser l'application qui vient d'être livrée.

Comme vous pouvez le constater, ce n'est pas aussi simple que le lancement d'un traitement de texte.

Qu'est ce que Tomcat ?

Tomcat est un produit Open Source sous licence "Apache" développé et maintenu par le groupe de travail Apache Jakarta Project.

En simplifiant, dans le monde des serveurs Java, il existe 3 catégories :

Les serveurs de Servlets : Tomcat, ServletExec, JRun. Ils implémentent les spécifications SERVLET et JSP (Java Server Page).

Les serveurs d'EJB : Jboss, Jonas. Ils implémentent les spécifications EJB.

Les serveurs d'applications : WebSphere, BEA, WebLogic. Ces derniers sont pour la plupart des produits commerciaux et fournissent une implémentation des spécifications SERVLET, EJB dans le même produit. Ils proposent également des services supplémentaires, des connecteurs applicatifs et des interfaces de gestion.

Quels sont les avantages de Tomcat ?

Versions de Tomcat

Chacune de ces versions apportent en plus de l'implémentation des spécifications, des fonctionnalités propriétaires et des interfaces d'administration améliorés.

Deploiement de Java et Tomcat

Tomcat ne peut s'exécuter qu'à l'intérieur d'une machine virtuel Java, il faut donc télécharger et installer le kit de développement Java.

Téléchargement

Remarque : Pour le binaire ou le RPM du JDK, il faut utiliser le click-droit de la souris et passer par le menu enregistrer-sous sinon le lien va ouvrir le contenu du fichier dans la fenêtre du navigateur

Installation du Kit de développement Java en version binaire

Remarque : Le JRE (Java Runtime Environment) permet d'exécuter du code Java, le JDK (Java Development Kit) permet de compiler du java et contient également le JRE. Le JRE et le JDK font partis du J2SE (Java 2 , Standard Edition)


# Activez le mode exécutable pour le fichier binaire téléchargé :
[root@linux /]$ chmod +x j2sdk-1_4_2_03-linux-i586.bin

# Exécutez le binaire :
[root@linux /]$ ./j2sdk-1_4_2_03-linux-i586.bin

# Acceptez les conditions de la licence.

# La version binaire à la particularité de se déployer à l'endroit où elle se trouve. 
# Vous trouverez donc à la fin de l'installation un répertoire j2sdk1.4.2_XX.

# Déplacez le répertoire et créez un lien symbolique :
[root@linux /]$ mv ./j2sdk1.4.2_xx /usr
[root@linux /]$ cd /usr
[root@linux /]$ ln -s j2sdk1.4.2_xx java
# Vérifiez le bon fonctionnement en affichant la version de java : [root@linux /]$ /usr/java/bin/java -version

Remarque : Le fait de créer un lien symbolique est un reflexe à prendre car au moment ou vous mettrez à jour le JDK, vous n'aurez pas à désinstaller systématique l'ancienne version et vous n'aurez aucune modification à faire dans les fichiers de configuration car ils utiliseront tous le chemin : "/usr/java"


Installation du Kit de développement Java en version RPM


# Activez le mode exécutable pour le fichier binaire téléchargé :
[root@linux /]$ chmod +x j2sdk-1_4_2_03-linux-i586-rpm.bin

# Exécutez le binaire :
[root@linux /]$ ./j2sdk-1_4_2_03-linux-i586-rpm.bin

# Dérouler la page et tapez "yes" pour accepter les conditions d'utilisations de la licence.
# Le programe va extraire un fichier RPM.

# Lancez l'installation du RPM (avec -U pour Update au cas ou une version existerait déja) :
[root@linux /]$ rpm -Uvh j2sdk-1_4_2_03-linux-i586.rpm

# Après l'installation vous trouverez le répertoire /usr/java/j2sdk1.4.2_03.

# Le problème de la version RPM est qu'elle s'installe déja dans un sous répertoire /usr/java

# Créez un lien symbolique :
[root@linux /]$ cd /usr/java
[root@linux /]$ ln -s j2sdk1.4.2_xx j2sdk

# Vérifiez le bon fonctionnement en affichant la version de java :
[root@linux /]$ /usr/java/j2sdk/bin/java -version

# Supprimez le binaire téléchargé et le RPM extrait de ce binaire :
[root@linux /]$ rm -f j2sdk-1_4_2_03-linux-i586-rpm.bin
[root@linux /]$ rm -f j2sdk-1_4_2_03-linux-i586.rpm

Remarque : Le RPM du JDK, créer un répertoire /etc/.java pour stocker des préférences propres au système et à l'environnement. Le fonctionnement de ces préférences sera décrit dans une documentation spécifique à Java.


Environnement d'exécution pour Java

Remarque : Vous n'êtes pas obligé d'intégrer les variables suivantes, si vous n'utilisez java que pour l'exécution de Tomcat et que vous les ajoutez à l'environnement de l'utilisateur tomcat. Voir le chapitre sur l'installation du serveur Tomcat.
# Pour tous les paramétrages suivant, nous partirons du principe que vous avez utilisé le 
# binaire et non le RPM du kit Java. Donc tous les appels à java seront fait par le chemin /usr/java

# Ajoutez la variable JAVA_HOME :
[root@linux /]$ export JAVA_HOME=/usr/java

# Ajoutez le chemin des binaires Java dans la variable PATH :
[root@linux /]$ export PATH=$PATH:$JAVA_HOME/bin


Installation de Tomcat

# Nous partirons du principe que vous installez Tomcat dans /usr/local/jakarta-tomcat-4.1.29

# Décompressez le binaire téléchargé :
[root@linux /]$ tar -xzvf jakarta-tomcat-4.1.29.tar.gz -C /usr/local

# Créez un lien symbolique :
[root@linux /]$ cd /usr/local
[root@linux /]$ ln -s jakarta-tomcat-4.1.29 tomcat

# Créez un compte utilisateur pour l'exécution de Tomcat (avec shell et home) :
[root@linux /]$ useradd tomcat

# Placez les variables d'environnements nécessaires à Tomcat :
[root@linux /]$ echo 'export JAVA_HOME=/usr/java' >> /home/tomcat/.bash_profile
[root@linux /]$ echo 'export PATH=$PATH:$JAVA_HOME/bin' >> /home/tomcat/.bash_profile
[root@linux /]$ echo 'export CATALINA_HOME=/usr/local/tomcat' >> /home/tomcat/.bash_profile

# Cette option est utilisé pour forcer java à utiliser l'ISO-8859-1 lors de compilation de pages JSP
[root@linux /]$ echo 'export JAVA_OPTS=-Dfile.encoding=ISO-8859-1' >> /home/tomcat/.bash_profile

# Contrôlez le bon fonctionnement de l'environnement de l'utilisateur tomcat :
[root@linux /]$ su - tomcat -c 'java -version'
[root@linux /]$ su - tomcat -c 'echo $CATALINA_HOME'

# Modifiez les droits des répertoires et fichiers de Tomcat :
[root@linux /]$ cd /usr/local/tomcat
[root@linux /]$ chown tomcat.tomcat -R work temp logs conf

Répertoires et fichiers d'installation Tomcat

Partie principale


/usr/local/tomcat...: Racine/HOME
|
|-- bin
|   |-- startup.sh..........: Démarrage du serveur
|   |-- shutdown.sh.........: Arrêt du serveur
|   |-- catalina.sh.........: Script utilisé par startup.sh et shutdown.sh  
|   |-- jspc.sh.............: Compilation offline de pages JSP 
|   |-- digest.sh...........: ?
|   |-- jasper.sh...........: Script utilisé par jspc.sh
|   |-- setclasspath.sh.....: Script utilisé par à peu près tous les autres scripts
|   |-- tool-wrapper.sh.....: Script utilisé par digest.sh 
|   |-- *.jar...............: Librairies contenant le code java principal pour l'execution du serveur 
|   |-- *.bat et tomcat.exe.: Ces fichiers ne sont utilisés que sous Windows, vous pouvez les supprimer 
|
|-- common
|   |-- classes.............: Fichiers .class partageables avec le serveur et toutes les applications
|   |-- endorsed............: Je manque de maitrise sur ce sujet
|   |-- lib.................: Librairies .jar partageables avec le serveur et toutes les applications
|
|-- conf....................: Contient les fichiers de configurations du serveur
|   |-- server.xml..........: Fichier de configuration du serveur
|   |-- web.xml.............: Fichier de configuration des valeurs par défaut pour toutes les applications WEB
|   |-- tomcat-users.xml....: Fichier XML contenant les comptes pour l'administration Intranet de Tomcat 
|   |-- catalina.policy.....: Paramétrage de la sécurité d'exécution Java - Non utilisé par défaut
|   |-- jk2.properties......: Fichier d'exemple pour la configuration du connecteur Apache HTTP JK2
|
|-- logs....................: Fichiers de logs
|
|-- server	
|   |-- classes.............: Pour placer des fichiers .class utilisables seulement par le serveur
|   |-- lib.................: Pour placer des librairies .jar utilisables seulement par le serveur
|
|-- shared
|   |-- classes.............: Pour placer des fichiers .class utilisables seulement par les applications WEB
|   |-- lib.................: Pour placer des librairies .jar utilisables seulement par les applications WEB
|
|-- temp....................: Fichiers temporaires générés par le serveur
|
|-- webapps.................: Répertoire de déploiement des applications WEB
|
|-- work....................: Répertoire de compilation. Transformation des pages .JSP en fichiers .class

Structure d'une application WEB

Remarque : Chaque application WEB dispose de son propre répertoire qui devient son contexte d'exécution.

/usr/local/tomcat
|
|-- webapps..............: Répertoire de déploiement des applications WEB
|   |  
|   |-- examples.........: Racine de l'application WEB "examples"  
|   |   | 
|   |   |-- index.jsp....: Page d'index de l'application
|   |   | 
|   |   |-- WEB-INF......: Répertoire de configuration de l'application
|   |   |   | 
|   |   |   |-- web.xml..: Fichier de configuration propre à l'application
|   |   |   | 
|   |   |   |-- classes..: Peut contenir des fichiers .class visibles uniquement par l'application
|   |   |   | 
|   |   |   |-- lib......: Peut contenir des fichiers .jar visibles uniquement par l'application
 

Configuration du serveur Tomcat

Fichier server.xml après nettoyage et commentaires


# Balise Server : le port est utilisé pour l'envoi d'un code d'arrêt par le programme Java appelé par 
# la commande shutdown.sh. Ce port n'est accessible par défaut qu'a partir de la machine (localhost)
<Server port="8005" shutdown="SHUTDOWN" debug="0">

   # Composants utilisés pour l'administration de Tomcat
   <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
   <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" debug="0"/>

   # Ressources Globales, utilisables pour l'ensemble des applications Web
   <GlobalNamingResources>

      # Définition d'une Resource
      # Base de données java des comptes utilisateurs avec chargement à partir d'un fichier XML
      <Resource 
         name="UserDatabase" 
         auth="Container" 
         type="org.apache.catalina.UserDatabase"
         description="User database that can be updated and saved">
      </Resource>
			
      <ResourceParams name="UserDatabase">
         <parameter>
            <name>factory</name>
            <value>org.apache.catalina.users.MemoryUserDatabaseFactory</value>
         </parameter>
         <parameter>
            <name>pathname</name>
            <value>conf/tomcat-users.xml</value>
         </parameter>
      </ResourceParams>

   </GlobalNamingResources>
  
   <Service name="Tomcat-Standalone">

      # Connecteur HTTP permettant d'accèder directement à Tomcat par un 
      # lien de type http://host-tomcat:8080/examples.
      # Ce connecteur peut être désactivé si vous utilisez Apache avec le connecteur JK1 ou JK2	
      <Connector 
         className="org.apache.coyote.tomcat4.CoyoteConnector"
         port="8080" 
         minProcessors="5" 
         maxProcessors="75"
         enableLookups="true" 
         redirectPort="8443"
         acceptCount="100" 
         debug="0" 
         connectionTimeout="20000"
         useURIValidationHack="false" 
         disableUploadTimeout="true"
      />

      # Connecteur JK2 (mod_jk2) pour relier le serveur HTTP Apache à Tomcat.
      # Le lien s'établit entre le serveur HTTP Apache et le serveur Tomcat par le port TCP 8009
      # Laissez ce connecteur en commentaire, nous y reviendrons.
      <!--
      <Connector 
         className="org.apache.coyote.tomcat4.CoyoteConnector"
         port="8009" 
         minProcessors="5" 
         maxProcessors="75"
         enableLookups="true" 
         redirectPort="8443"
         acceptCount="10" 
         debug="0" 
         connectionTimeout="0"
         useURIValidationHack="false"
         protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"
      />
      -->

      # Connecteur JK1 (mod_jk) pour relier le serveur HTTP Apache à Tomcat.
      # Le lien s'établit entre le serveur HTTP Apache et le serveur Tomcat par le port TCP 8009
      # Normalement ce connecteur n'est plus utilisé et doit être remplacé par JK2
      <!--
      <Connector 
         className="org.apache.ajp.tomcat4.Ajp13Connector"
         port="8009" 
         minProcessors="5" 
         maxProcessors="75"
         acceptCount="10" 
         debug="0"
      />
      -->

      <Engine name="Standalone" defaultHost="localhost" debug="0">
				 
         # Connecteur d'authentification personnalisé.
         # La classe UserDatabaseRealm, utilise un fichier XML pour authentifier les utilisateurs 
         <Realm 
            className="org.apache.catalina.realm.UserDatabaseRealm"
            debug="0" 
            resourceName="UserDatabase"
         />

         # Exemple d'un connecteur d'authentification utilisant une base de données SQL
         <!--
         <Realm  
            className="org.apache.catalina.realm.JDBCRealm" 
            debug="99"
            driverName="org.gjt.mm.mysql.Driver"
            connectionURL="jdbc:mysql://localhost/authority"
            connectionName="test" 
            connectionPassword="test"
            userTable="users" 
            userNameCol="user_name" 
            userCredCol="user_pass"
            userRoleTable="user_roles" 
            roleNameCol="role_name" 
         />
         -->

         <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">

            # Logger au niveau du Host pour tous les Context
            <Logger 
               className="org.apache.catalina.logger.FileLogger"
               directory="logs"  
               prefix="localhost_log." 
               suffix=".txt"
               timestamp="true"
            />
				
            # Application WEB "examples" accèssible par un ligne http://host/examples 
            # ou http://host:8080/examples 
            <Context path="/examples" docBase="examples" debug="0" reloadable="true" crossContext="true">

               # Logger au niveau de l'application 
               <Logger 
                  className="org.apache.catalina.logger.FileLogger"
                  prefix="localhost_examples_log." 
                  suffix=".txt"
                  timestamp="true"
               />
					
               # Définition d'une ressource 
               <Resource name="mail/Session" auth="Container" type="javax.mail.Session"/>

               <ResourceParams name="mail/Session">
                  <parameter>
                     <name>mail.smtp.host</name>
                     <value>localhost</value>
                  </parameter>
               </ResourceParams>
				
            </Context>
				
         </Host>	

      </Engine>
	
   </Service>

</Server>

Fichier web.xml du serveur après nettoyage et commentaires

En cours...

Sécurité - Authentification

Il existe plusieurs façon de gérer l'authentification auprès d'un serveur Tomcat. Chacune répond à un besoin et des moyens différents.

Authentification - Besoins :
Authentification - Moyen :
Authentification - Techniques :
Service d'authentification fournie par Tomcat :

Dans le fichier server.xml, vous trouverez des balises "Realm" contenant des exemples de configuration d'un connecteur d'authentification utilisable pour toutes les applications ou pour une seule.

Si vous placez un connecteur "Realm" à l'extérieur d'une balise "Context", par exemple dans "Engine" ou "Host", celui-ci sera disponible pour toutes les applications et permettra en plus d'activer des fonctions de SSO (Single Sign On).

Dans le cas contraire, le connecteur ne sera disponible que pour l'application dans lequel il est inséré.

Des exemples de configurations sont fournies sur le site de Tomcat.

Exécution du serveur Tomcat


# Lancer le serveur :
[root@linux /]$ su - tomcat -c "/usr/local/tomcat/bin/startup.sh"

# Arrêter le serveur :
[root@linux /]$ su - tomcat -c "/usr/local/tomcat/bin/shutdown.sh"

# Ligne de commande exécutée (répartie sur plusieurs lignes pour une meilleure lisibilité) :
/usr/java/bin/java \ 
java -Djava.endorsed.dirs=/usr/local/tomcat/common/endorsed \ 
-classpath /usr/java/lib/tools.jar:/usr/local/tomcat/bin/bootstrap.jar \ 
-Dcatalina.base=/usr/local/tomcat \
-Dcatalina.home=/usr/local/tomcat \
-Djava.io.tmpdir


# Tomcat se lance à partir du script startup.sh et les options décrites ci-dessous 
# doivent être utilisés à travers la variable d'environnement CATALINA_OPTS

# Options en ligne de commande par le script catalina.sh à travers la variable CATALINA_OPTS :
> CATALINA_OPTS=start             : Tomcat en mode normal en arrière plan (*** par défaut)
> CATALINA_OPTS=start -security   : Tomcat en mode normal en arrière plan avec le security manager
> CATALINA_OPTS=debug             : Tomcat en mode debuggage  
> CATALINA_OPTS=debug -security   : Tomcat en mode debuggage avec le security manager
> CATALINA_OPTS=jpda start        : Tomcat sous le debugger JPDA
> CATALINA_OPTS=embedded          : Tomcat en mode embarqué   
> CATALINA_OPTS=run               : Tomcat en mode normal
> CATALINA_OPTS=run -security     : Tomcat en mode normal avec le security manager 
> CATALINA_OPTS=stop              : Arrêt de tomcat     

# L'utilisation de l'option "-security" force java à utiliser le fichier catalina.policy dont
# la syntaxe est propre à Java.

# Variables d'environnement : Seul CATALINA_HOME et JAVA_HOME sont obligatoires.

# Répertoire de base pour le serveur Tomcat
CATALINA_HOME="/usr/local/tomcat"

# Répertoire de base pour le serveur Tomcat
CATALINA_BASE="$CATALINA_HOME"

# Options d'exécution du serveur Tomcat (par défaut c'est l'option start qui est utilisé)
CATALINA_OPTS="start"

# Répertoire des fichiers temporaires Tomcat
CATALINA_TMPDIR="$CATALINA_BASE/temp"

# Répertoire de base pour le kit de développement Java
JAVA_HOME="/usr/java/j2sdk1.4.2_03"

# Options d'exécution de la machine virtuel Java
JAVA_OPTS=

# Type de connection vers le debugger java - Seulement si tomcat est lancé en mode debug avec l'option "jpda" 
JPDA_TRANSPORT="dt_socket"

# Port TCP du debugger java - Seulement si tomcat est lancé en mode debug avec l'option "jpda" 
JPDA_ADDRESS="8000"

# Répertoire de base du package JSSE (Seulement pour l'utilisation de Tomcat avec SSL)
# Le package JSSE se télécharge en dehors du JDK sur le site de Sun.
# Chemin vers : $JSSE_HOME/lib/jcert.jar:$JSSE_HOME/lib/jnet.jar:$JSSE_HOME/lib/jsse.jar
JSSE_HOME=

# Chemin complet vers un fichier qui contiendra le numéro de processus (pid) du serveur Tomcat
CATALINA_PID=

Gestion des logs

La gestion des logs est très modulaire avec Tomcat. La configuration se fait principalement dans le fichier server.xml à travers des entrées XML <Logger>

Le fichier server.xml permet de charger des composants de façon hiérarchisés : Server -> Service -> Engine -> Context

A l'intérieur de chacune de ces balises XML vous pouvez définir un "Logger" qui se chargera de journaliser les informations en rapport avec le niveau sous lequel il est exécuté.

Si vous définissez une seule entrée "Logger" sous la balise "Engine", toutes les sorties java pour ce moteur, seront redirigées vers ce fichier.

Si laissez le "Logger" sous la balise "Engine" et que vous ajoutez une entrée "Logger" sous chaque balise "Context", vous aurez le Logger de l'Engine qui contiendra toutes les sorties java, exceptées celles qui seront journalisées dans le Logger de chaque "application" inscrites dans les balises "Context".

Les entrées "Logger" peuvent être placés sous les balises "Engine", "Host" et "Context". Si aucune entrée "Logger" n'est placé dans server.xml alors toutes les sorties java se trouveront dans catalina.out.

# logs/catalina.out est généré par les scripts de lancement et d'arrêt du 
# serveur Tomcat et ne dépend pas du fichier server.xml.

# Ajout d'un logger au niveau de la balise "Engine" :
<Server port="8005" shutdown="SHUTDOWN" debug="0">
   ...
   <Service name="Tomcat-Standalone">
      ...
      <Engine name="Standalone" defaultHost="localhost" debug="0">	     		
         <Logger 
            className="org.apache.catalina.logger.FileLogger"
            directory="logs"  
            prefix="engine-standalone." 
            suffix=".log"
            timestamp="true"
         />		
         ...
      </Engine>		   
      ...  
   </Service>    		
</Server>


# Ajout d'un logger supplémentaire pour une application WEB au niveau d'une balise "Context" :
<Server port="8005" shutdown="SHUTDOWN" debug="0">
   ...
   <Service name="Tomcat-Standalone">
      ...
      <Engine name="Standalone" defaultHost="localhost" debug="0">	     		
         <Logger 
            className="org.apache.catalina.logger.FileLogger"
            directory="logs"  
            prefix="engine-standalone." 
            suffix=".log"
            timestamp="true"
         />
         ...
         <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
            ...				
            <Context path="/examples" docBase="examples" debug="0" reloadable="true" crossContext="true">
               <Logger 
                  className="org.apache.catalina.logger.FileLogger"
                  prefix="app-examples." 
                  suffix=".log"
                  timestamp="true"
               />
               ...																   
            </Context>
            ...													
         </Host>			 
      </Engine>		   
   </Service>    		
</Server>

Il existe une extension particulièrement interressante pour la gestion des logs, il s'agit de LOG4J qui se présente sous la forme d'une API livré dans un fichier ".jar".

Je consacrerais une documentation entière à Log4J, car c'est un sujet très vaste.

Pour l'exemple, sachez que Log4J vous permettrait de rediriger tous vos logs de Tomcat vers Syslog

Installation et mise à jour d'une application WEB

Le mauvaise exemple de certains fournisseurs ou développeurs :

Vous l'avez peut être compris en lisant cette documentation, une application Web que l'on dit utilisable sur un serveur de servlet 2.3 doit pouvoir être déployée sur n'importe produit respectant cette norme.

Malheureusement certaines sociétés ou développeurs, par manque d'expérience ou n'ayant pas bien saisi le concept des applications Web, transforment Tomcat en programme propriétaire quasiment impossible à maintenir autrement qu'en passant par eux.

Les conséquences :

Bien sûr, c'est un peu caricatural mais pourtant très proches de ce que j'ai pûs voir en clientèle.

Comment vérifier la conformité d'une application Web :


Le déploiement :

Selon le format dans lequel est livré l'application et selon l'environnement, les méthodes diffères.

Le format des livrables :

Déploiement d'un fichier War :

Si vous n'avez pas désactivé le déploiement automatique des applications .war dans server.xml, le simple fait de copier l'archive dans le répertoire "webapps" devrait déclencher son installation.

Si c'est une mise à jour, le nouveau contenu devrait remplacer l'ancien. Mais attention ce n'est pas si simple.

Je pourrais vous décrire une cinquantaine façon de déployer chaque application mais je vous conseille la suivante :

Surveillance et maintenance

 

Intégration Tomcat / Apache

 

Mise à jour de Tomcat

 

Conclusions

 

Remerciements

Merci à Olivier ALLARD-JACQUIN pour la charte graphique dont je me suis totalement inspiré.

Liens