1. Structure globale
1.1 Examiner l'architecture globale du processus de traitement des demandes
Comme le montrent les figures 1 et 2 de la figure ci-dessus :
- Dans la figure 1, le serveur HTTP appelle directement des classes métier spécifiques, et chaque programme d'application et serveur sont étroitement couplés.
Dans cette architecture, HTTP doit accepter différentes requêtes et appeler différentes classes pour traiter les requêtes en fonction de différentes requêtes
. Le serveur HTTP fonctionnera sous une charge élevée pendant une longue période et devra ouvrir l'interface d'appel avec chaque classe. - Dans la figure 2, le serveur HTTP n'appelle pas directement la classe affaires, mais transmet la demande au conteneur pour traitement, et le conteneur
appelle la classe affaires via l'interface Servlet. L'apparence de l'interface Servlet et du conteneur Servlet dissocie
le serveur HTTP des différentes classes métier. L'interface Servlet et le conteneur Servlet suivent la spécification Servlet.
Tomcat implémente le conteneur Servlet conformément aux exigences de la spécification Servlet, et ils ont également
la fonction de serveur HTTP. Si vous souhaitez implémenter de nouvelles fonctions métier, il vous suffit d'implémenter un servlet et de l'enregistrer dans
Tomcat (conteneur de servlet), et Tomcat s'occupera du reste.
1.2 Flux de travail du conteneur de servlets
Lorsqu'un seul utilisateur demande une certaine ressource, le serveur HTTP utilisera un objet ServletRequest pour encapsuler les
informations de demande du client, puis appellera la méthode de service du conteneur de servlet. Une fois que le conteneur de servlet aura reçu la demande
, il trouvera le correspondant Si le Le servlet n'a pas
été chargé, utilisez le mécanisme de réflexion pour créer le servlet et appelez la méthode init du servlet pour terminer l'initialisation
, puis appelez la méthode de service du servlet pour traiter la demande et renvoyez l'objet ServletResponse
au serveur HTTP. Le serveur envoie la réponse au client.
1.3 Architecture globale de Tomcat
Tomcat est conçu pour implémenter deux fonctions principales :
- Gérez la connexion Socket, copiez la conversion du flux d'octets réseau et les objets Request et Response.
- Chargez et gérez le servlet et gérez les fonctions spécifiques des requêtes Request.
Par conséquent, Tomcat a conçu deux composants principaux : le connecteur (connecteur) et le conteneur (Container) pour
accomplir ces deux choses respectivement. Le connecteur est responsable du traitement externe et le conteneur est responsable du traitement interne.
2. Détails architecturaux
2.1 Connecteur Coyote (connecteur)
Coyote est le nom du framework de connecteurs de Tomcat et c'est l'
interface externe fournie par le serveur Tomcat pour l'accès client. Le client établit une connexion avec le serveur via Coyote, envoie des requêtes et reçoit des réponses.
2.1.1 Interaction entre Coyote et Catalina
Coyote encapsule la communication réseau sous-jacente (traitement des requêtes et des réponses du socket),
fournit une interface unifiée pour le conteneur Catalina et dissocie complètement le conteneur Catalina du protocole de requête spécifique et du mode de fonctionnement IO.
Coyote encapsule la conversion d'entrée Socket en tant qu'objet Request, qui est traité par le conteneur Catalina
. Une fois le traitement terminé, Catalina écrit le résultat dans le flux de sortie via l'objet Response fourni par Coyote.
En tant que module indépendant, Coyote n'est responsable que de protocoles spécifiques et d'opérations liées aux E/S, et
n'a aucune relation directe avec l'implémentation de la spécification Servlet. Par conséquent, même les objets Request et Response n'implémentent pas
l'interface correspondante de la spécification Servlet, mais ils sont encapsulés dans Catalina sous le nom de ServletRequest et
ServletResponse.
2.1.2 Modèle et protocole IO
Dans Coyote, Tomcat prend en charge une variété de modules d'E/S et de protocoles de couche d'application. Le tableau suivant montre les modèles d'E/S pris en charge par Tomcat
(à partir de la version 8.9/9.0, Tomcat a supprimé la prise en charge de BIO)
| Modèle d'E/S | décrire |
|---|---|
| NIO | E/S non bloquantes, implémentées à l'aide de la bibliothèque de classes Java NIO |
| NIO2 | E/S asynchrones, implémentées à l'aide de la dernière bibliothèque de classes NIO2 du JDK 7 |
| AVR | Il est implémenté par la bibliothèque d'exécution portable Apache, qui est une bibliothèque native écrite en c/c++. Si vous choisissez ce modèle, vous devez installer la bibliothèque APR. |
Protocoles de couche application pris en charge par Tomcat :
| protocole | illustrer |
|---|---|
| HTTP/1.1 | C'est le protocole utilisé par la plupart des applications Web |
| AJP | Utilisé pour s'intégrer au serveur Web (Apache) pour optimiser les ressources statiques et le déploiement de cluster, prend actuellement en charge AJP/1.3 |
| HTTP/2 | HTTP 2.0 améliore considérablement les performances Web. Pris en charge après Tomcat8.5 et 9.0. |
Relations entre les couches de protocole dans Tomcat
| couche d'application | HTTP | AJP | HTTP2 |
| couche de transport | NIO | NIO2 | AVR |
Afin de prendre en charge plusieurs modèles d'E/S et protocoles de couche application dans Tomcat, un conteneur peut se connecter à plusieurs connecteurs.
Cependant, les connecteurs ou conteneurs individuels ne peuvent pas fournir de services externes et doivent être combinés pour fonctionner. L'
ensemble combiné est appelé un composant de service. Il est à noter que le Service n'implique pas
le traitement de la requête, mais joue uniquement le rôle d'encapsulation du connecteur et du conteneur. Le serveur Tomcat peut être configuré avec plusieurs services,
conçus pour plus de flexibilité. De cette manière, en configurant plusieurs services dans Tomcat,
différentes applications déployées sur le même serveur sont accessibles via différents ports.
2.1.3 Assemblage du connecteur
Le rôle de chaque sous-composant dans le composant connecteur :
Endpoint
- Endpoint est le point final de communication de Coyote et l'interface de surveillance de la communication. Il s'agit d'un processeur Socket spécifique
de réception et d'envoi et d'une abstraction de la couche de transport. Par conséquent, Endpoint est utilisé pour implémenter le
protocole TCP/IP. - Tomcat n'a pas d'interface Endpoint, mais fournit une classe abstraite AbstractEndpoint, qui
définit deux classes internes : Acceptor et SocketProcessor. L'accepteur est utilisé pour écouter
les requêtes Socket. SocketProcessor est utilisé pour traiter la requête Socket reçue, il implémente l'interface Runnable et
appelle le composant de traitement de protocole Processor dans la méthode Run pour le traitement. Afin d'améliorer les performances de traitement,
SocketProcessor est soumis au pool de threads pour exécution. Et ce pool de threads s'appelle l'exécuteur (Executor)
Processeur Processor
est l'interface de traitement du protocole Coyote, Endpoint implémente le protocole ICP/IP et Processor
est l'abstraction du protocole HTTP. Le processeur reçoit le socket du point de terminaison, lit le flux d'octets et l'analyse
en objets de requête et de réponse Tomcat, puis les soumet au conteneur pour traitement via l'adaptateur.
ProtocolHandler
ProtocolHandler est une interface de protocole Coyote, via Endpoint et Processor, elle réalise
la capacité de traitement pour des protocoles spécifiques. Le protocole d'installation et les E/S Tomcat fournissent six classes d'implémentation : AjpNioProtocol,
AjpAprProtocol, AjpNio2Protocol, Http11NioProtocol, Http11Nio2Protocol,
Http11AprProtocol. Lors de la configuration de tomcat/conf/server.xml, vous devez au moins spécifier un
ProtocolHandler spécifique, bien sûr, vous pouvez également spécifier un nom de protocole, tel que : HTTP/1.1, si APR est suivi, alors
Http11AprProtocol sera utilisé, sinon, Http11NioProtocol sera utilisé.
En raison des différents protocoles de l'Adaptateur
, les informations de demande envoyées par le client sont également différentes. Tomcat définit sa propre
classe Request pour encapsuler ces informations de demande. L'interface ProtocolHandler est chargée d'analyser la requête et de générer la classe Tomcat Request.
Mais cet objet Request n'est pas un servletRequest standard, ce qui signifie que Tomcat Request ne peut pas être utilisé
comme paramètre pour appeler le conteneur. La solution du concepteur Tomcat consiste à introduire CoyoteAdapter, qui est une
application classique du mode adaptateur. Le connecteur appelle la méthode Service de CoyoteAdapter et l'objet Tomcat Request est transmis.
CoyoteAdapter est responsable de la conversion de Tomcat Request en servletRequest, puis appelle le Méthode de service
du conteneur.
2.2 Conteneur Catalina (conteneur de servlets)
2.2.1 La position de Catalina dans les composants Tomcat
Tomcat est un conteneur Web composé d'une série de composants configurables, et catalina est essentiellement
le conteneur de servlets de Tomcat. Catalina est une implémentation d'un conteneur de servlets. Il intègre coyote de manière faiblement couplée
pour effectuer la lecture et l'écriture des données selon le protocole de demande.
Tomcat est essentiellement un conteneur de servlets, donc catalina est le cœur de Tomcat, et d'autres modules
prennent en charge catalina. Par exemple : la communication par lien est fournie via le module coyote, le moteur JSP est fourni par le module Jasper
, le service JNDI est fourni par Naming et le service de journalisation est fourni par Juli.
2.2.2 Structure Catalina
Structure des composants principaux de Catalina
Comme le montre la figure ci-dessus, Catalina est responsable de la gestion du serveur et le serveur représente l'ensemble du serveur. Il existe plusieurs services sous Server
, et chaque service contient plusieurs composants de connecteur (implémentation coyote) et un
conteneur de composants conteneur. Au démarrage de Tomcat, une instance de catalina sera initialisée.
Le rôle de chaque composant de Catalina :
| Composants | effet |
|---|---|
| Catalina | Responsable de l'analyse des fichiers de configuration romcat pour créer des composants de serveur et les gérer selon les commandes |
| Serveur | Serveur : représente l'intégralité du conteneur de servlet Catalina et d'autres composants, responsables de l'assemblage et du démarrage du moteur de servlet, du connecteur Tomcat. Le serveur offre un moyen élégant de démarrer et d'arrêter l'ensemble du système en implémentant l'interface Lifecycle. |
| service | Un service est un composant interne d'un serveur et un serveur contient plusieurs services. Il lie plusieurs composants de connecteur à un conteneur (moteur) |
| Connecteur | Le connecteur gère la communication avec le client, il est responsable de la réception de la demande du client, puis la transfère vers le conteneur approprié pour traitement et renvoie enfin le résultat de la réponse au client. |
| Récipient | Le conteneur est responsable du traitement de la demande de servlet de l'utilisateur et du renvoi de l'objet au module de l'utilisateur Web. |
2.2.3 Structure du conteneur
Tomcat a conçu 4 types de conteneurs, à savoir Engine, Host, Context et Wrapper. Ces 4 types de conteneurs
ne sont pas des relations parallèles, mais des relations parent-enfant. Tomcat rend le conteneur Servlet très flexible grâce à son architecture en couches
.
La signification de chaque composant :
| composant de conteneur | illustrer |
|---|---|
| Moteur | Représente le moteur de servlet de l'ensemble de catalina, utilisé pour gérer plusieurs sites virtuels, un service ne peut avoir qu'un seul moteur au maximum, mais un moteur peut contenir plusieurs hôtes |
| Hôte | Représente un hôte virtuel ou un site. Tomcat peut être configuré avec plusieurs adresses d'hôte virtuel et un hôte virtuel peut contenir plusieurs contextes |
| Contexte | Représente une application Web et une application Web peut contenir plusieurs Wrappers |
| Emballage | Représente un servlet, Wrapper est la couche inférieure du conteneur et ne peut pas contenir de sous-conteneurs |
Nous pouvons également utiliser le fichier de configuration server.xm1 de Tomcat pour approfondir notre compréhension du conteneur Tomcat.
Tomcat adopte une conception composée de composants et ses composants sont tous configurables. La couche la plus externe est le serveur et
d'autres composants sont configurés dans ce conteneur de niveau supérieur selon certaines exigences de format. Le cadre de configuration est le suivant :
<Server ... >
<Service ... >
<Connector ... > ... </Connector>
<Connector ... > ... </Connector>
<Engine ... >
<Realm ... > ... </Realm>
<Realm ... > ... </Realm>
<Host ... >
<Valve ... />
</Host>
</Engine>
</Service>
</Server>
Comment Tomcat gère-t-il ces conteneurs ?En regardant de plus près la configuration ci-dessus, vous constaterez que ces conteneurs ont une relation parent-enfant,
formant une structure arborescente, vous pouvez immédiatement penser au modèle de conception Java 组合模式. C'est vrai, Tomcat
utilise le mode combinaison pour gérer ces conteneurs. La méthode d'implémentation spécifique est que tous les composants du conteneur implémentent l'interface Container
, de sorte que le mode combinaison peut permettre aux utilisateurs d'utiliser l'objet conteneur unique et l'objet conteneur combiné avec cohérence. Ici,
l'objet conteneur unique fait référence au wrapper inférieur et l'objet conteneur composite fait référence au contexte ci-dessus, hôte ou
moteur.
3. Détails de démarrage de Tomcat
3.1 Processus de démarrage de Tomcat
Étapes de démarrage UML pour Tomcat :
- Pour démarrer Tomcat, vous devez appeler bin/startup.sh (dans le répertoire Windows, vous devez appeler
bin/startup.bat), et dans le script startup.sh, appeler catalina.sh. - Dans le fichier de script catalina.sh, la méthode principale de Bootstrap est appelée.
- La méthode init est appelée dans la méthode principale de Bootstrap pour créer catalina et initialiser
le chargeur de classe. - La méthode load est appelée dans la méthode main de BootStrap et la méthode 1load de Catalina y est appelée
. - Dans la méthode 1load de catalina, un travail d'initialisation est requis et un
objet Digester doit être construit pour analyser le fichier de configuration XML. - Appelez ensuite l'opération d'initialisation des composants suivants...
Enfin, chargez le fichier de configuration romcat, initialisez le composant Arrow pour écouter le numéro de port correspondant et préparez-vous à accepter les demandes des clients.
3.2 Composants impliqués dans le processus de démarrage de Tomcat
3.2.1 Interface de cycle de vie
Étant donné que tous les composants ont des méthodes de cycle de vie telles que l'initialisation, le démarrage et l'arrêt, et ont les caractéristiques de gestion du cycle de vie,
romcat est conçu sur la base de la gestion du cycle de vie et résumé dans une interface Cycle de vie, tandis que
les composants Serveur, Service, Conteneur, Exécuteur, Connecteur, les deux implémentez une
interface de cycle de vie, ayant ainsi les méthodes de base suivantes dans le cycle de vie :
init():Module d'initialisationstart(): composant de démarragestop(): composant d'arrêtdestroy():détruire le composant
3.3.2 L'implémentation par défaut de chaque composant
Le serveur, le service, le moteur, l'hôte et le contexte mentionnés ci-dessus sont tous des interfaces, et les
classes d'implémentation par défaut de ces interfaces sont présentées dans la figure ci-dessous. Pour le composant Endpoint, il n'y a pas d'interface Endpoint correspondante dans Tomcat, mais il existe
une classe abstraite AbstractEndpoint, sous laquelle se trouvent trois classes d'implémentation : NioEndpoint, Nio2Endpoint,
AprEndpoint, ces trois classes d'implémentation correspondent à l'explication précédente de l'éditeur de liens Coyote, Les trois modèles I0 mentionnés pris en charge par l'éditeur de liens
: NIO, NIO2 et APR, dans la version Tomcat8.5, NioEndpoint est adopté par défaut.
ProtocolHandler : interface de protocole Coyote, en encapsulant le point de terminaison et le processeur, il réalise
la fonction de traitement pour des protocoles spécifiques. Tomcat propose 6 classes d'implémentation selon le protocole et Io.
Protocole AJP :
- AjpNioProtocol : Adoptez le modèle I0 de NIo.
- AjpNio2Protocol : adoptez le modèle I0 de NIO2.
- AjpAprProtoco1 : Le modèle I0 utilisant APR doit dépendre de la bibliothèque APR.
Protocole HTTP : je
Http11NioProtocol : Il adopte le modèle IO de NIO, qui est le protocole utilisé par Tomcat par défaut (si le serveur n'installe pas APR).- Http11Nio2Protocol : Adoptez le modèle I0 de NIO2.
- Http11AprProtocol : le modèle I0 utilisant APR doit dépendre de la bibliothèque APR.
4. Le processus de traitement des demandes Tomcat
4.1 Processus de demande
Avec autant de couches de conteneurs conçues, comment Tomcat détermine-t-il quel servlet dans le conteneur Wrapper doit gérer chaque requête ?
La réponse est : Tomcat utilise le composant Mapper pour effectuer cette tâche.
La fonction du composant Mapper est de localiser l'URL demandée par l'utilisateur à un servlet. Son principe de fonctionnement est le suivant : les informations de
configuration de l'application Web sont enregistrées dans le composant Mapper, qui est en fait la relation de mappage entre le composant conteneur et le chemin d'accès,
tel que le nom de domaine configuré dans le conteneur Host, le chemin de l'application Web dans le conteneur Context et
le chemin de mappage du servlet dans le conteneur wrapper, vous pouvez imaginer que ces informations de configuration sont une carte à plusieurs niveaux.
Lorsqu'une requête arrive, le composant Mapper peut localiser un servlet en analysant le nom de domaine et le chemin dans l'URI de la requête, puis en recherchant dans la Map enregistrée par lui-même . Veuillez noter qu'une URL ne ciblera
finalement qu'un seul conteneur Wrapper, qui est un servlet.
Dans le diagramme ci-dessous, il décrit
comment trouver le servlet qui gère finalement la logique métier après que l'utilisateur a demandé le lien http://www.suosuoli.cn/articles/tomcat.
L'image ci-dessus décrit uniquement comment trouver le servlet à exécuter en fonction de l'URI demandé.Analysons
le traitement des requêtes de Tomcat du point de vue de l'architecture de conception de Tomcat.
Les étapes spécifiques sont les suivantes :
- L'accepteur du composant Connecteur Endpoint écoute la connexion du socket client et reçoit le socket.
- La connexion est transmise à l'exécuteur du pool de threads pour traitement et la tâche de réponse à la demande est démarrée.
- Le composant Processeur lit le message, analyse la ligne de demande, le corps de la demande et l'en-tête de la demande, et l'encapsule dans un objet Request.
Le composant Mapper correspond au conteneur hôte, au conteneur de contexte et au conteneur Wrapper qui traitent la demande en fonction de la valeur URL de la ligne de demande et de la valeur Host de l'en-tête de la demande .- Le composant CoyoteAdaptor est chargé d'associer le composant Connector au conteneur Engine, de transmettre l'
objet Request généré et l'objet de réponse Response au conteneur Engine et d'appeler le Pipeline. - Le pipeline du conteneur Engine commence le traitement. Le pipeline contient plusieurs vannes, et chaque vanne est responsable d'une partie de la
logique de traitement. Une fois la valve exécutée, la valve de base sera exécutée, c'est-à-dire la StandardEnginevalve, qui est responsable de
l'appel du pipeline du conteneur hôte. - Le pipeline du conteneur Host commence à traiter, le processus est similaire, et enfin le Pipeline du conteneur Context est exécuté.
- Le pipeline du conteneur Context commence à traiter, et le processus est similaire, et s'exécute finalement sur le pipeline du conteneur wrapper.
- Le pipeline du conteneur wrapper commence le traitement, le processus est similaire, et exécute enfin la méthode de traitement de l'objet Servlet correspondant au conteneur Wrapper
.
4.2 Analyse du code source du processus de demande
Dans l'architecture globale de Tomcat, nous avons constaté que chaque composant de Tomcat remplit ses propres tâches et que le couplage lâche entre les composants garantit l'
évolutivité et l'évolutivité de l'architecture globale.
Comment améliorer la flexibilité et l'extensibilité des composants à l'intérieur des composants ?
Dans Tomcat, chaque composant Container adopte le mode chaîne de responsabilité pour effectuer le traitement des demandes spécifiques.
Deux interfaces, Pipeline et Valve, sont définies dans Tomcat. Pipeline est utilisé pour construire la chaîne de responsabilité, et cette dernière
représente chaque processeur de la chaîne de responsabilité. Une valve de base est conservée dans le Pipeline, qui est toujours située à
la fin du Pipeline (exécutée à la fin), et encapsule le processus de traitement des demandes spécifiques et de réponse de sortie. Bien sûr, nous pouvons également appeler
la méthode addvalve() pour ajouter d'autres vannes au pipeline, et les vannes ajoutées sont situées
avant les vannes de base et sont exécutées dans l'ordre d'ajout. Pipiline démarre l'exécution de la chaîne d'intégration en récupérant la première valve.
5. Moteur Jaspe
5.1 Présentation du moteur Jasper
Pour les applications Web basées sur JSP, nous pouvons écrire directement des codes Java dans les pages Jsp, ajouter des bibliothèques de balises tierces
et utiliser des expressions EL. Mais quelle que soit la forme de traitement, le résultat final destiné au client est une
page HTML standard (y compris js, css... ) et ne contient aucune syntaxe liée à Java. En d’autres termes,
nous pouvons considérer jsp comme un script exécuté côté serveur. Alors, comment le serveur convertit-il la page Jsp en
page HTML ?
Le module Jasper est le moteur principal JSP de Tomcat, nous savons que JSP est essentiellement un servlet.
Tomcat utilise Jasper pour analyser la syntaxe Jsp, générer un servlet et générer le bytecode de classe.
Lorsque les utilisateurs visitent jsp, ils visiteront Servlet et répondront enfin au résultat directement au navigateur. De plus,
lors de l'exécution, Jasper vérifiera également si le fichier Jsp est modifié, et s'il est modifié, il recompilera le fichier Jsp.
En un mot : Jasper analyse .JSPla page et génère celle correspondante Servlet, qui est finalement compilée dans .classun fichier bytecode
5.2 Méthode de compilation Jasper
5.2.1 Compilation au moment de l'exécution
Tomcat ne compile pas automatiquement le fichier Jsp lors du démarrage de l'application Web, mais compile uniquement le fichier Jsp auquel il faut accéder lorsque le client le demande pour la première fois .
Vous pouvez utiliser un cas pour comprendre la compilation d'exécution, créer un projet Web et écrire du code JSP de test :
<%@ page import="java. text.DateFormat" %>
<%@ page import="java.text .SimpleDateFormat" %>
<%@ page import="java.util.Date" %>
<%@ page contentType="text/html; charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
<title>$Title$</title>
</head>
<body>
<%
DateFormat dateFormat = new SimpleDateFormat ("yyyy-MM-dd HH:mm:ss") ;
String format = dateFormat. format (new Date ()) ;
%>
Hello，Java Server Page 。。。。
<br/>
<%= format %>
</body>
</html>
5.2.1.1 Processus de compilation
Tomcat configure un org.apache.jasper.servlet.JspServlet dans le web.xml par défaut, qui
est utilisé pour gérer toutes .jspou .jspxterminer les requêtes, et l'implémentation de ce servlet est le point d'entrée de la compilation du runtime.
<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>
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.jspx</url-pattern>
</servlet-mapping>
5.2.2 Résultats de la compilation
-
Si
tomcat/conf/web.xmlle paramètre scratchdir est configuré dans , le résultat de la compilation jsp
sera stocké dans ce répertoire.<init-param> <param-name>scratchdir</param-name> <param-value>/tmp/jsp/</param-value> </init-param> -
Si cette option n'est pas configurée, le résultat compilé sera stocké dans le répertoire d'installation de Tomcat
work/Catalina(Engine名称)/localhost(Host名称)/Context名称. En supposant que
le nom du projet estjsp_demo_01, le répertoire par défaut est :work/Catalina/localholt/jsp_demo_01.
5.2.3 Précompilation
En plus de compiler au moment de l'exécution, il est également possible de compiler toutes les pages Jsp de l'application Web en même temps directement au démarrage de l'application Web . Dans ce cas, lors de l'exécution de l'application Web, il n'est pas nécessaire d'effectuer une compilation en temps réel,
mais d'appeler directement le servlet correspondant à la page Jse pour terminer le traitement de la requête, améliorant ainsi les performances du système.
Tomcat fournit un programme shell JspC pour prendre en charge la précompilation JSP et
fournit un fichier catalina-tasks.xml dans le répertoire d'installation de Tomcat pour déclarer les tâches Ant prises en charge par Tomcat. Par conséquent,
nous pouvons facilement utiliser Ant pour exécuter JSP précompilé.
(Pour utiliser cette méthode, vous devez vous assurer qu'Apache Ant a été téléchargé et installé avant ).