Tutoriel pour comprendre la précompilation des pages JSP sous Tomcat

Même s'il est propre au conteneur web, le sujet de la compilation des pages JSP est assez récurrent sur les projets, cela donne l'impression d'avoir une application plus lente compte tenu du fait que celle-ci intervient lors premier accès à l'application. Du point de vue du client, c'est une notion difficile à appréhender, car il désire une application immédiatement opérationnelle et rapide, sans pour autant se préoccuper des caractéristiques techniques. On cherche donc à occulter simplement ce phénomène. Pour cela, nous allons voir ce qu'est qu'une JSP, comment cela fonctionne, ainsi que les solutions disponibles pour remédier à ce problème. Ensuite, nous implémenterons une solution simple et générique qui va en plus nous permettre de comprendre comment fonctionnent les JSP ainsi que d'autres notions en Java. D'ici la fin de cet article, vous serez en mesure de régler définitivement ce problème.

Pour bien comprendre le sujet, regardons déjà les différentes solutions existantes, cela va nous permettre de comprendre un peu plus le sujet et nous donner des idées. Pour réduire le périmètre de recherche, nous utiliserons Tomcat comme conteneur web, nous allons donc regarder comment Tomcat gère la compilation.

Pour remédier à la solution de la compilation des fichiers JSP, la fondation Apache propose une solution basée sur un script ant dans sa documentation, au chapitre JSPs et paragraphe "Web Application Compilation". Il y est expliqué qu'il est nécessaire d'exécuter une tâche ant qui est fournie dans la documentation et non dans le produit Tomcat.

Cette tâche réalise plusieurs étapes :

• génération du code Java à partir des fichiers JSP ;
• compilation du code Java en bytecode Java ;
• génération du fichier "generated_web.xml" contenant la correspondance des URL avec les servlets.

Ce qui est intéressant dans ce script, c'est l'import au début du fichier catalina-tasks.xml. Celui-ci utilise les librairies fournies dans Tomcat pour compiler les JSP. Au début du script, on importe un autre script ant déjà présent dans votre Tomcat, dans le répertoire bin/ : catalina-tasks.xml. Ce script spécifie les librairies utilisées pour la compilation des fichiers JSP. Jetons un œil à la version de ce script pour Tomcat 7.0.50 pour comprendre son fonctionnement :

<project name="catalina-tasks">
    <description>Catalina Ant Manager, JMX and JSPC Tasks</description>
    <!-- set catalina.home if it's not already set -->
    <dirname property="catalina.home.bin.dir" file="${ant.file.catalina-tasks}" />
    <property name="catalina.home" value="${catalina.home.bin.dir}/.." />
    <typedef resource="org/apache/catalina/ant/catalina.tasks">
        <classpath>
            <fileset file="${catalina.home}/bin/tomcat-juli.jar" />
            <fileset file="${catalina.home}/lib/tomcat-api.jar" />
            <fileset file="${catalina.home}/lib/tomcat-util.jar" />
            <fileset file="${catalina.home}/lib/jasper.jar" />
            <fileset file="${catalina.home}/lib/jasper-el.jar" />
            <fileset file="${catalina.home}/lib/el-api.jar" />
            <fileset file="${catalina.home}/lib/JSP-api.jar" />
            <fileset file="${catalina.home}/lib/servlet-api.jar" />
            <fileset file="${catalina.home}/lib/catalina-ant.jar" />
            <fileset file="${catalina.home}/lib/tomcat-coyote.jar" />
        </classpath>
    </typedef>
    <typedef resource="org/apache/catalina/ant/jmx/jmxaccessor.tasks">
        <classpath>
            <fileset file="${catalina.home}/lib/catalina-ant.jar" />
        </classpath>
    </typedef>
</project>

Ce script importe des tâches ant contenues dans deux fichiers, catalina.tasks et jmxaccessor.tasks qui se trouvent eux-mêmes dans le fichier catalina-ant.jar.

Pour la compilation des JSP, c'est la première définition qui nous intéresse, c'est-à-dire org/apache/catalina/ant/catalina.tasks. Elle contient les implémentations utilisées pour chaque définition ant et celle qui nous intéresse est jasper=org.apache.jasper.JspC. Si vous voulez connaitre en détail ce que fait la tâche ant jasper, vous pouvez regarder cette classe.

On a donc trois paramètres à définir pour cette tâche :

• uriroot permet de définir le chemin d'accès aux fichiers JSP ;
• outputDir permet de définir le répertoire contenant les fichiers Java qui seront générés ;
• webXmlFragment permet de définir le fichier generated_web.xml généré contenant les déclarations des servlets.

Voici un exemple de fichier generated_web.xml généré :

<!-- Automatically created by Apache Tomcat JspC. Place this fragment in 
    the web.xml before all icon, display-name, description, distributable, and 
    context-param elements. -->

<servlet>
    <servlet-name>org.apache.jsp.error_JSP</servlet-name>
    <servlet-class>org.apache.jsp.error_JSP</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>org.apache.jsp.error_JSP</servlet-name>
    <url-pattern>/error.jsp</url-pattern>
</servlet-mapping>

Ensuite, à partir de cela, Java compile les fichiers générés (définis dans la tâche compilée).

Par exemple :

Reprenons le contenu du fichier generated_web.xml. On peut constater que notre fichier error.jsp correspond pour l'application à la classe java org.apache.jsp.error_JSP.class. Cela signifie qu'à l'exécution, l'application n'utilise pas le fichier JSP mais directement la classe java issue du fichier JSP. On pourrait tout à fait livrer une application uniquement avec les classes Java et sans les JSP.

Ce script utilise le même moteur de Tomcat, mais pendant la phase de compilation avant exécution de l'application. Si nous n'utilisons pas ce script, le même traitement est exécuté au premier appel de chaque page.

Vous pouvez faire le test :

• lancez l'application ;
• allez dans le répertoire work de Tomcat, il est vide ;
• accédez avec votre navigateur web sur la page error.jsp ;
• retournez dans le répertoire work et recherchez le fichier org.apache.jsp.error_JSP.java et org.apache.jsp.error_JSP.class.

Avec le script ant, le traitement est identique, mais vous avez constaté en effectuant ce test que la page ne s'affiche pas tout de suite, car Tomcat a effectué tout un traitement avant le rendu de la page :

• vérification que l'instance n'existe pas ;
• génération du fichier Java ;
• génération du fichier Classe ;
• création de l'instance ;
• ajout dans le pool de JSP (JSPServlet).

Donc, pour éliminer ce phénomène, il suffirait de lancer le script avant le démarrage de Tomcat.

En fait, ce n'est pas tout à fait le cas : nous avons juste créé les fichiers ".class" et la généré le fichier web.xml. Cependant, nous ne les avons pas intégrés dans notre application, donc il y a encore des étapes à réaliser avant que cela soit opérationnel.

Maintenant, avec ces informations, prenons un cas concret :

• nous avons une webapp représentée par un simple fichier war ;
• nous avons le produit Tomcat et on y insère, dans le répertoire webapp, notre fichier war ;
• nous lançons l'application avec le script startup.sh.

L'idéal serait d'utiliser le script en n'effectuant aucune autre opération supplémentaire pour garder cette procédure.

La seule action possible est le lancement du traitement de compilation au début du script startup.sh (par exemple). Pour cela, nous devons effectuer ces traitements :

• décompresser tous les fichiers war dans le répertoire webapp ;
• appeler la tâche ant de compilation ;
• récupérer le contenu du fichier generated_web.xml et le rajouter dans le fichier web.xml de l'application ;
• et pour finir lancer le traitement d'origine du fichier startup.sh.

Contrairement à ce qu'on pouvait penser au début, il ne suffit pas de lancer le script ant pour réaliser quelque chose de simple et fonctionnel. Après avoir ajouté tous les traitements, nous avons quelque chose d'opérationnel... enfin pas forcément...

Si notre webapp utilise la nouvelle fonctionnalité apportée par la spécification Servlet 3, qui consiste à mettre les fichiers JSP dans les fichiers jar, notre solution ne fonctionnera pas.

Petite explication :

Une application web est représentée par une archive war. Cette archive a forcément un fichier web.xml, qui décrit le fonctionnement de l'application web, un répertoire WEB-INF/classes et surtout un répertoire WEB-INF/lib, qui peut contenir des fichiers jar.

Les fichiers statiques peuvent se trouver n'importe où dans le fichier war, mais pas directement dans les fichiers jar. C'est pour cela que, sur de nombreux projets, on fusionne plusieurs webapps (maven overlay).

Depuis Servlet 3, il est possible de placer ces fichiers dans un jar du moment que ces fichiers se trouvent dans le répertoire META-INF/resources du jar.

Une fonctionnalité fort pratique quand on a une application modulable, mais qui ne nous facilite pas la tâche pour la compilation avec la méthode officielle.

Cela va rajouter des étapes supplémentaires : nous devons récupérer le contenu du répertoire META-INF/resources de chaque jar de l'application et compiler les fichiers JSP trouvés...

En regardant la solution officielle, cela nous a permis de comprendre le fonctionnement des JSP, ses possibilités et ses inconvénients. Regardons une autre solution possible qui a le même principe, mais pendant la phase de packaging de l'application.

La solution à la compilation :

Cette solution n'a pas la même approche que la précédente.

Le plug-in maven-JSPc-plugin me plait beaucoup, car, comme tout outil maven, il offre la possibilité d'être piloté facilement.

Il permet de réaliser la même tâche que le script ant que nous avons expliqué, à la seule différence qu'il est utilisé à la construction de l'application.

L'idée est séduisante, car la mise en place du plug-in est simplifiée par l'utilisation de maven.

À la compilation des JSP, l'outil a besoin des dépendances utilisées dans la page JSP, par exemple : les scriptlet, les taglibs, etc. qui sont en général déclarées avec le scope “runtime”.

Malheureusement, le plug-in maven n'exploite pas les dépendances déclarées en runtime et l'exécution du plug-in échoue.

À part mettre toutes les dépendances avec le scope par défaut, ce qui n'est pas pratique, ce plug-in n'est pas utilisable.

De plus, ce plug-in utilise une version spécifique de Jasper. Même si l'implémentation de ce dernier ne bouge pas souvent, cela comporte un risque. Par exemple, si un jour, il y a une migration de version de Tomcat, nous serons peut-être dans l'obligation de recompiler la webapp...

Nous venons de lister deux solutions existantes qui sont assez différentes.

• Une solution officielle qui fonctionne, mais qui contraint à fournir du travail pour la mettre en place.
• Une solution très simple d'utilisation, mais qui ne fonctionne pas dans tous les cas.

Ces deux solutions utilisent toujours le moteur de compilation de Tomcat Jasper.

Essayons, grâce aux connaissances que l'on vient d'acquérir, de proposer une solution compatible pour toutes les versions de Tomcat et qui permette à l'utilisateur de réaliser le minimum d'actions possibles.

Avant de coder, essayons de poser chaque élément en fonction de ce que nous venons de voir et de trouver un début de réponse :

Quels sont les besoins ?

• Ne plus avoir le temps de latence sur la première invocation des pages de notre application.
• Savoir si on n'a pas de problème de syntaxe dans nos fichiers JSP.
• Faciliter la mise en place de cette fonctionnalité, quelle que soit l'application web.

La solution est de pré-compiler les pages avant la libération du contexte par le conteneur web. En regardant la spécification Servlet (Chapitre 14), nous apprenons que le point d'entrée d'une application web est le fichier web.xml. Ce fichier permet de déclarer des servlets, des filters et des listeners. Les listeners permettent d'écouter certains événements, il en existe de différentes sortes. Par exemple, le listener ServletContextListener est déclenché au démarrage et à l'arrêt de l'application web.

Donc notre point de départ est :

• implémenter un listener Web ;
• celui-ci va récupérer tous les fichiers JSP de l'application ;
• compiler les fichiers JSP.

Pour mieux comprendre le fonctionnement, regardons comment la compilation est exécutée par défaut avec Tomcat.

En cherchant un peu dans le produit Tomcat, on tombe sur le fichier web.xml et on découvre un passage intéressant :

<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>

<!-- 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>

Chaque URL qui se termine par .jsp ou .jspx exécute en réalité la Servlet JSPServlet.

En regardant le code de cette Servlet, on découvre le fonctionnement du rendu d'une page. Prenons la page test.jsp, et effectuons deux tests. Le premier test à la première invocation, le second test à la seconde invocation. La page est accessible avec l'URL : http:\\localhost:8080\compile\WEB-INF\JSP\test.jsp.

À la première invocation :

1. L'utilisateur accède avec son navigateur à l'URL : http:\\localhost:8080\compile\WEB-INF\JSP\test.jsp ;;
2. Tomcat intercepte l'appel et exécute la servlet JSPServlet car l'URL se termine par ".jsp" ;
3. JSPServlet regarde dans son pool si une instance représentant test.jsp est créée ;
4. JSPServlet génère le fichier Java et le compile ensuite, car aucune instance n'existe dans son pool. Le fichier généré est lui-même une servlet ;
5. JSPServlet instancie la nouvelle servlet qu'il vient de compiler et la place dans son pool ;
6. JSPServlet exécute la nouvelle servlet et envoie le rendu au navigateur.

À la deuxième invocation :

1. L'utilisateur accède avec son navigateur à l'URL : http:\\localhost:8080\compile\WEB-INF\JSP\test.jsp ;
2. Tomcat intercepte l'appel et exécute la servlet JSPServlet car l'URL se termine par ".jsp" ;
3. JSPServlet regarde dans son pool si une instance représentant test.jsp est créée;
4. JSPServlet récupère l'instance de la servlet test.jsp et l'exécute pour rendu au navigateur.

La phase de compilation de la JSP se trouve dans la classe JspServletWrapper. Cette classe invoque ensuite l'implémentation que nous avons vue au préalable dans le script ant. Cette classe possède une méthode service avec un commentaire décrivant le traitement pour chaque étape :

1. compile ;
2. (Re)load servlet class file ;
3. handle limitation of number of loaded Jsps ;
4. service request.

Ici, nous n'avons besoin que des deux premières étapes, puisque nous voulons juste compiler et charger la servlet. Et en regardant de plus près le code, nous trouvons ce commentaire :

// If a page is to be precompiled only, return.
    if (precompile) {
      return;
    }

Cela signifie qu'il y a un paramètre qui permet juste de compiler les pages.

On continue notre recherche pour retrouver à quoi correspond ce booléen et on trouve la réponse dans la classe JspServlet de la méthode "preCompile". En lisant le code, on comprend rapidement à quoi cela sert et il y a même un commentaire très intéressant :

/**
* <p>Look for a <em>precompilation request</em> as described in
* Section 8.4.2 of the JSP 1.2 Specification. <strong>WARNING</strong> -
* we cannot use <code>request.getParameter()</code> for this, because
* that will trigger parsing all of the request parameters, and not give
* a servlet the opportunity to call
* <code>request.setCharacterEncoding()</code> first.</p>
*
* @param request The servlet request we are processing
*
* @exception ServletException if an invalid parameter value for the
* <code>jsp_precompile</code> parameter name is specified
*/

On nous indique le numéro du chapitre de la spécification expliquant le fonctionnement.

En résumé :

L'accès d'une page avec le paramètre jsp_precompile, par exemple, http:\\localhost:8080\compile\WEB-INF\JSP\test.jsp?jsp_precompile, permet de lancer le traitement de compilation en n'effectuant que les deux premières étapes. Si on reprend notre exemple de tout à l'heure, cela donne :

1. L'utilisateur accède avec son navigateur à l'URL : http:\\localhost:8080\compile\WEB-INF\JSP\test.jsp?jsp_precompile ;
2. Tomcat intercepte l'appel et exécute la servlet JSPServlet car l'URL se termine par ".jsp" ;
3. JSPServlet regarde dans son pool si une instance représentant test.jsp est créée ;
4. JSPServlet génère le fichier Java et le compile ensuite, car aucune instance n'existe dans son pool. Le fichier généré est lui-même une servlet ;
5. JSPServlet instancie la nouvelle servlet qu'il vient de compiler et la place dans son pool.

Donc, en conclusion de cette partie, nous devrons implémenter un listener pour récupérer le chemin d'accès à chaque "JSP" et "JSPx" et invoquer chaque fichier en ajoutant le paramètre jsp_precompile.

Nous devrons donc réaliser un listener qui récupère les chemins d'accès de chaque fichier "JSP" de l'application en cours de démarrage et les compiler.

III-A. Récupérer toutes les JSP▲

static Set<String> findFilesInDirectory(final ServletContext servletContext, final String dirPath, final String... fileExtensions) {
    final Set<String> files = new HashSet<String>();

    for (final String path : servletContext.getResourcePaths(dirPath)) {

      if (path.endsWith("/")) {
        final Set<String> findFilesInDirectory = findFilesInDirectory(servletContext, path, fileExtensions);
        files.addAll(findFilesInDirectory);
      } else {
        for (final String extension : fileExtensions) {
          if (path.endsWith("." + extension)) {
            files.add(path);
          }
        }
      }
    }
    return files;
  }

final Set<String> JSPs = JspCompileHelper.findFilesInDirectory(servletContext, "/", "JSP", "JSPx");

III-B. Invoquer chaque ressource▲

III-C. Implémentation de HttpServletRequest et HttpServletResponse▲

static HttpServletRequest createHttpServletRequest() {
    final InvocationHandler handler = new InvocationHandler() {

      public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable {
        final String methodName = method.getName();

        if (methodName.equals("getQueryString")) {
          return "jsp_precompile";
        }
        if (methodName.equals("isAsyncSupported")) {
          return false;
        }
        if (methodName.equals("isAsyncStarted")) {
          return false;
        }

        return null;
      }
    };

    return (HttpServletRequest) Proxy.newProxyInstance(JspCompileHelper.class.getClassLoader(),
        new Class<?>[]{HttpServletRequest.class}, handler);
  }

(HttpServletRequest) Proxy.newProxyInstance(JspCompileHelper.class.getClassLoader(),
 new Class<?>[]{HttpServletRequest.class}, handler);

public class TestHttpServletRequest implements HttpServletRequest {

 @Override
 public String getQueryString() {
 return "jsp_precompile";
 }
 
 @Override
 public boolean isAsyncStarted() {
 return false;
 }

 @Override
 public boolean isAsyncSupported() {
 return false;
 }
 
 @Override
 public Object getAttribute(String name) {
 return null;
 }

 @Override
 public Enumeration<String> getAttributeNames() {
 return null;

etc.

III-D. Implémentation du Listener▲

  public void contextInitialized(final ServletContextEvent servletContextEvent) {

    final ServletContext servletContext = servletContextEvent.getServletContext();

    // Récupere tous les fichiers JSP et JSPx présent dans l'application.
    final Set<String> JSPs = JspCompileHelper.findFilesInDirectory(servletContext, "/", "JSP", "JSPx");

    // Création d'un requete et d'une réponse pour la compilation
    final HttpServletRequest request = JspCompileHelper.createHttpServletRequest();
    final HttpServletResponse response = JspCompileHelper.createHttpServletResponse();

    for (final String JSP : JSPs) {
      final RequestDispatcher requestDispatcher = servletContext.getRequestDispatcher(JSP);

      try {
        servletContext.log("Compiling : " + servletContext.getContextPath() + JSP);
        requestDispatcher.include(request, response);
      } catch (final Exception e) {
        // Exception est déjà tracée par le logger de tomcat.
        // Tomcat 7.0.50 - ApplicationDispatcher.invoke Line 772
      }
    }
  }

III-E. Web Fragments▲

<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
    version="3.0">

    <listener>
        <display-name>Jsp Compile Listener</display-name>
        <listener-class>fr.ms.tomcat.listener.jsp.JspCompileListener</listener-class>
    </listener>

</web-fragment>

III-F. On peut faire mieux▲

III-G. Compilation en tâche de fond▲

class JspCompileRunnable implements Runnable {

  private final ServletContext servletContext;
  private final String path;

  private final HttpServletRequest request;
  private final HttpServletResponse response;

  /**
   * Créer une instance de {@link Runnable} permettant de réaliser un include sur un ressource.
   * 
   * @param servletContext La {@link ServletContext} à utiliser pour la compilation.
   * @param path Le chemin d'accès de la ressource.
   * @param request la {@link HttpServletRequest requete} à utiliser pour la compilation.
   * @param response la {@link HttpServletRequest réponse} à utiliser pour la compilation.
   */
  JspCompileRunnable(final ServletContext servletContext, final String path, final HttpServletRequest request,
      final HttpServletResponse response) {
    this.servletContext = servletContext;
    this.path = path;
    this.request = request;
    this.response = response;
  }

  public void run() {

    final RequestDispatcher requestDispatcher = servletContext.getRequestDispatcher(path);

    if (requestDispatcher == null) {
      return;
    }

    try {
      servletContext.log("Compiling : " + servletContext.getContextPath() + path);
      requestDispatcher.include(request, response);
    } catch (final Exception e) {
      // Exception est déjà tracée par le logger de tomcat.
      // Tomcat 7.0.50 - ApplicationDispatcher.invoke Line 772
    }
  }
}

  public void contextInitialized(final ServletContextEvent servletContextEvent) {

    final ServletContext servletContext = servletContextEvent.getServletContext();

    // Récupere tous les fichiers JSP et JSPx présent dans l'application.
    final Set<String> JSPs = JspCompileHelper.findFilesInDirectory(servletContext, "/", "JSP", "JSPx");

    // Création un executor avec un seul thread daemon et la priorité la plus basse.
    final ThreadFactory threadFactory = new JspCompileThreadFactory(servletContext.getContextPath());
    final Executor executorService = Executors.newSingleThreadExecutor(threadFactory);

    // Création d'une requête et d'une réponse pour la compilation
    final HttpServletRequest request = JspCompileHelper.createHttpServletRequest();
    final HttpServletResponse response = JspCompileHelper.createHttpServletResponse();

    for (final String JSP : JSPs) {
      final Runnable task = new JspCompileRunnable(servletContext, JSP, request, response);
      executorService.execute(task);
    }
  }

III-H. Thread Factory▲

class JspCompileThreadFactory implements ThreadFactory {

  private final ThreadFactory threadFactory = Executors.defaultThreadFactory();

  private final String name;

  JspCompileThreadFactory(final String name) {
    this.name = name;
  }

  public Thread newThread(final Runnable r) {
    final Thread newThread = threadFactory.newThread(r);

    if (name != null) {
      newThread.setName("JSPCompile " + name);
    }

    newThread.setDaemon(true);
    newThread.setPriority(Thread.MIN_PRIORITY);

    return newThread;
  }
}

final ThreadFactory threadFactory = new JspCompileThreadFactory(servletContext.getContextPath());
Executor executorService = Executors.newSingleThreadExecutor(threadFactory);

<dependency>
    <groupId>com.github.marcosemiao.tomcat.listener</groupId>
    <artifactId>JSP-compile-listener</artifactId>
    <version>1.0.0</version>
</dependency>

Cet article a été publié avec l'aimable autorisation de SOAT, société d'expertise et de conseil en informatique.

Nous tenons à remercier ced pour la relecture orthographique et Mickaël Baron pour la mise au gabarit.