Lorsque vous installez un module CQ5 contenant une nouvelle version du code de nos /applications (contenant des fichiers .jsp ou .java) le code JSP ne se recompile pas intégralement après l'installation du module.
 

Solution

Pour résoudre ce problème pour une installation unique, procédez comme suit :

1. Connectez-vous à http://<host>:<port>/crx en tant qu'administrateur (où <host> est le nom d'hôte ou l'adresse IP de votre serveur CQ5 et <port> est le numéro de port).
2. Ouvrez l'outil CRX Explorer.
3. Supprimez les nœuds présents sous /var/classes/org/apache/jsp/apps/.

Pour résoudre ce problème et garantir que JSP soit recompilé à chaque installation du module, modifiez votre module comme suit :

1. Ajoutez deux règles de filtrage au début de votre fichier filter.xml (dans META-INF/vault/filter.xml)
   

   <workspaceFilter version="1.0"> <filter root="/var/classes/org/apache/jsp/apps" /> <filter root="/var/classes/apps" /> ...
   

2. Ajoutez ensuite deux dossiers vides /var/classes/org/apache/jsp/apps et /var/classes/apps dans le fichier zip de votre module. Ainsi, lorsque vous installez le module, tous les fichiers de classe situés à cet emplacement seront supprimés. Par conséquent, cela entraînera la recompilation de tous les fichiers JSPs et Java d’application dans le répertoire /apps du module par Apache Sling.

Application

CQ5.2, CQ5.3 sans le correctif 30517

Informations supplémentaires

Ce problème est dû à la manière dont Apache Sling évalue si vous souhaitez compiler un fichier JSP ou Java donné.

La date jcr:lastModified du script est comparée à la date du fichier de classe existant sjcr:lastModified.

Si la date de la dernière modification du script est plus récente que celle du fichier de classe, il est recompilé. Dans le cas contraire, il n'est pas recompilé.

Lorsque vous mettez en module un fichier zip contenant des fichiers jsp, certains fichiers JSP peuvent avoir des horodatages plus anciens que les fichiers de classe sous /var/classes.