Administration de Tomcat
1. Architecture de Tomcat
Tomcat est un serveur HTTP mais aussi un conteneur de servlet qui exécute des Servlet Java et en convertissant des JSP (JavaServer) et des JavaServerFaces (JSF) en servlet. Tomcat utilise une architecture hiérachique et modulaire de conteneurs qui est illustrée ici.
L’hiérarchie des conteneurs est la suivante :
- Server
- Service
- Engine
- Host
- Context
Cette hiérarchie se retrouvera dans le fichier conf/server.xml
.
2. Arborescence de l’installation Tomcat
yum -y install tree
tree -L 1 /opt/tomcat/latest/
/opt/tomcat/latest/
├── bin
├── BUILDING.txt
├── conf
├── CONTRIBUTING.md
├── lib
├── LICENSE
├── logs
├── NOTICE
├── README.md
├── RELEASE-NOTES
├── RUNNING.txt
├── temp
├── webapps
└── work
Voici quelques-uns des répertoires clés de tomcat :
/bin
- Démarrage, arrêt et autres scripts./conf
- Fichiers de configuration et DTD associées. Le fichier le plus important ici estserver.xml
. C’est le fichier de configuration principal du conteneur./logs
- Les fichiers journaux sont ici par défaut./webapps
- Emplacement des applications./lib
- Librairies et classes/work
- Dossier temporaire pour les applications
La variable CATALINA_HOME
:
export CATALINA_HOME=/opt/tomcat/latest
echo "export CATALINA_HOME=/opt/tomcat/latest" >> ~/.bashrc
3. Fichier server.xml
3.1. Fichier server.xml
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
</Engine>
</Service>
</Server>
3.2 Élément “Server”
Il y un serveur <Server port="8005" shutdown="SHUTDOWN">
qui contient un ou plusieurs services <Service name="Catalina">
qui contient ses connecteurs (HTTP/1.1
et AJP/1.3
) et Engine.
3.3. Élément “Listeners”
Un serveur comprend un ou plusieurs “Listeners” qui répondent à des événements spécifiques.
Par exemple le Listener GlobalResourcesLifecycleListener
active globalement les ressources, les JNDI, les possibilités de connexion à une base de données.
3.4. Élément “Global Naming Resources”
La directive “GlobalNamingResources” définit les ressources JNDI (Java Naming and Directory Interface), qui permet aux clients logiciels Java de découvrir et de rechercher des données et des objets via un nom.
C’est à cet endroit que l’on viendrait interfacer une base données.
3.5. Élément “Service”
Un “Service” associe un ou plusieurs “Connectors” à un “Engine”. On trouve deux connecteurs au service “Catalina” :
HTTP/1.1
sur le port TCP 8080AJP/1.3
sur le port TCP 8009
Un connecteur prend en charge les connexions TCP entre le Service et les clients.
3.6. Élément “Engine”
Un “Engine”, un moteur, est le plus haut niveau d’un conteneur. Il peut contenir un ou plusieurs hôtes.
On pourrait y configurer des hôtes virtuels (“virtual hosts”) pour exécuter Tomcat pour plusieurs noms.
3.7. Élément “Realm”
Un “Realm” est une base de données d’utilisateurs, de mots de passe et de rôles pour l’authentification (c’est-à-dire le contrôle d’accès). Vous pouvez définir un “Realm” pour n’importe quel conteneur, tel que “Engine”, “Host” et “Context”, et “Cluster”.
3.8. Élément “Host”
Un Host définit un hôte virtuel dans l’Engine, qui peut à son tour supporter de nombreux Contexts (webapps).
La configuration par défaut définit un hôte appelé localhost. L’attribut appBase définit le répertoire de base de toutes les webapps, dans ce cas, $CATALINA_HOME\webapps. Par défaut, l’URL de chaque webapp est la même que son nom de répertoire. Par exemple, l’installation par défaut de Tomcat fournit quatre webapps : docs, examples, host-manager et manager sous le répertoire webapps. La seule exception est ROOT, qui est identifié par une chaîne vide. C’est-à-dire, son URL est http://localhost:8080/
.
unpackWARs précise si un fichier WAR déposé dans le répertoire webapps doit être décompressé ou non. Avec unpackWARs=“false”, Tomcat lancera l’application directement depuis le fichier WAR, sans décompresser, ce qui pourrait signifier une exécution plus lente.
L’attribut autoDeploy spécifie si l’application doit être déployée automatiquement dans le répertoire webapps.
3.9. Élément “Valve”
Une “Valve” peut intercepter les requêtes HTTP avant de les transmettre aux applications, afin de pré-traiter les requêtes qui parviennent au serveur. Une “Valve” peut être définie pour n’importe quel conteneur, tel que “Engine”, “Host”, et “Context”, et “Cluster”.
Dans la configuration par défaut, l’élément AccessLogValve
intercepte une requête HTTP et crée une entrée de journal dans le fichier de logs.
On peut aussi exécuter d’autres actions :
RemoteAddrValve
: qui bloque les requêtes provenant de certaines adresses IP,RemoteHostValve
: qui bloque les requêtes basées sur les noms d’hôtes,RequestDumperValve
: qui enregistre les détails des demandes,SingleSignOn
: lorsqu’elle est placée sous un, permet à une connexion unique d’accéder à toutes les applications web sous l’hôte.
4. Fichier web.xml
Le fichier web.xml
est un descripteur de déploiement pour toutes les applications Web Java EE.
4.1. Début du fichier
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<!-- WARNING: Do not configure application-specific resources here! -->
<!-- They should go in the "/WEB-INF/web.xml" file in your application. -->
4.2. Built In Servlet Definitions and Servlet Mappings
Servlet par défaut (pages statiques)
Listing des pages : “false”
<!-- The default servlet for all web applications, that serves static -->
<!-- resources. It processes all requests that are not mapped to other -->
<!-- servlets with servlet mappings (defined either here or in your own -->
<!-- web.xml file). This servlet supports the following initialization -->
<!-- parameters (default values are in square brackets): -->
<!-- ================== Built In Servlet Definitions ==================== -->
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Servlet JSP
<!-- The JSP page compiler and execution servlet, which is the mechanism -->
<!-- used by Tomcat to support JSP pages. Traditionally, this servlet -->
<!-- is mapped to the URL pattern "*.jsp". This servlet supports the -->
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
<!-- NOTE: An SSI Filter is also available as an alternative SSI -->
<!-- implementation. Use either the Servlet or the Filter but NOT both. -->
<!-- -->
<!-- Server Side Includes processing servlet, which processes SSI -->
<!-- directives in HTML pages consistent with similar support in web -->
<!-- servers like Apache. Traditionally, this servlet is mapped to the -->
<!-- URL pattern "*.shtml". This servlet supports the following -->
<!-- ================ Built In Servlet Mappings ========================= -->
<!-- The servlet mappings for the built in servlets defined above. Note -->
<!-- that, by default, the CGI and SSI servlets are *not* mapped. You -->
<!-- must uncomment these mappings (or add them to your application's own -->
<!-- web.xml deployment descriptor) to enable these services -->
<!-- The mapping for the default servlet -->
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<!-- The mappings for the JSP servlet -->
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.jspx</url-pattern>
</servlet-mapping>
4.3. Built In Filter Definitions and Filter Mappings
Filtres avant traitement des requêtes.
Les filtres s’enchaînent dans l’ordre.
Plus d’informations sur les filtres Tomcat.
<!-- ================== Built In Filter Definitions ===================== -->
<!-- A filter that sets various security related HTTP Response headers. -->
<!-- This filter supports the following initialization parameters -->
<!--
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
</filter>
-->
<!-- A filter that triggers request parameters parsing and rejects the -->
<!-- request if some parameters were skipped because of parsing errors or -->
<!-- request size limitations. -->
<!--
<filter>
<filter-name>failedRequestFilter</filter-name>
<filter-class>
org.apache.catalina.filters.FailedRequestFilter
</filter-class>
<async-supported>true</async-supported>
</filter>
-->
<!-- ==================== Built In Filter Mappings ====================== -->
<!-- The mapping for the HTTP header security Filter -->
<!--
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
-->
<!-- The mapping for the Set Character Encoding Filter -->
<!--
<filter-mapping>
<filter-name>setCharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
-->
<!-- The mapping for the Failed Request Filter -->
<!--
<filter-mapping>
<filter-name>failedRequestFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
-->
4.4.Default Session Configuration
<!-- ==================== Default Session Configuration ================= -->
<!-- You can set the default session timeout (in minutes) for all newly -->
<!-- created sessions by modifying the value below. -->
<session-config>
<session-timeout>30</session-timeout>
</session-config>
4.5. Default MIME Type Mappings
<!-- ===================== Default MIME Type Mappings =================== -->
<!-- When serving static resources, Tomcat will automatically generate -->
<!-- a "Content-Type" header based on the resource's filename extension, -->
<!-- based on these mappings. Additional mappings can be added here (to -->
<!-- apply to all web applications), or in your own application's web.xml -->
<!-- deployment descriptor. -->
<!-- Note: Extensions are always matched in a case-insensitive manner. -->
4.6. Default Welcome File List
<!-- ==================== Default Welcome File List ===================== -->
<!-- When a request URI refers to a directory, the default servlet looks -->
<!-- for a "welcome file" within that directory and, if present, to the -->
<!-- corresponding resource URI for display. -->
<!-- If no welcome files are present, the default servlet either serves a -->
<!-- directory listing (see default servlet configuration on how to -->
<!-- customize) or returns a 404 status, depending on the value of the -->
<!-- listings setting. -->
<!-- -->
<!-- If you define welcome files in your own application's web.xml -->
<!-- deployment descriptor, that list *replaces* the list configured -->
<!-- here, so be sure to include any of the default values that you wish -->
<!-- to use within your application. -->
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
4.7. Fin du fichier
</web-app>
5. Fichier tomcat-users.xml
Ce fichier permet d’authentifier les utilisateurs de Tomcat.
Ici on définit un rôle “admin-gui” et “manager-gui” auxquelles on associe un utilisateur “admin”.
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="admin-gui"/>
<role rolename="manager-gui"/>
<user username="admin" password="XXXXXXXX" roles="admin-gui,manager-gui"/>
</tomcat-users>
Rôles manager :
manager-gui
: accès au GUI HTML et à la page de statutmanager-script
: accède à l’interface texte et à la page de statutmanager-jmx
: accède au proxy JMX et à la page de statutmanager-status
: accède uniquement à la page de statut
6. Fichier catalina.policy
… Renvoi sécurité … –> option -security
.
7. Configuration des ressources
La plateforme Java EE permet de se connecter à des ressources comme des serveurs de messagerie ou des bases de données grâce à un ensemble d’API de services.
L’API JNDI est un service de nommage permet d’organiser en noms les ressources rendues disponibles. Il fournit un mécanisme de recherche d’informations (par exemple dans un service d’annuaire LDAP).
8. Configuration d’un DataSource JDBC
Un pilote JDBC est un composant logiciel permettant à une application Java d’interagir avec une base de données. Les pilotes JDBC sont analogues aux pilotes ODBC, aux fournisseurs de données ADO.NET et aux fournisseurs OLE DB.
Pour se connecter à des bases de données individuelles, JDBC (Java Database Connectivity API) nécessite des pilotes pour chaque base de données. Le pilote JDBC fournit la connexion à la base de données et implémente le protocole de transfert de la requête et du résultat entre le client et la base de données.
Les pilotes de la technologie JDBC entrent dans l’une des quatre catégories suivantes :
- Pont JDBC-ODBC
- Pilote natif-API
- Pilote de protocole réseau (pilote Middleware)
- Pilote de protocole de base de données (pilote Pure Java) ou pilote léger.
9. Sessions JavaMail
…
10. JavaBeans
…
11. Entrées d’environnement
…