Los JSP no vuelven a compilar después de la instalación de un paquete de código

Cuando instala un paquete de CQ5 que contiene una nueva versión de nuestro código /apps (con archivos .jsp o .java), no todo el código JSP se vuelve a compilar después de instalar el paquete.

Solución

Para resolver este problema con una sola instalación, haga lo siguiente:

1. Inicie sesión en http://<host>:<port>/crx como administrador (donde <host> es el nombre de host o la dirección IP de su servidor CQ5 y <port>es el número de puerto).
2. Abra la herramienta CRX Explorer.
3. Elimine los nodos de /var/classes/org/apache/jsp/apps/.

Para resolver este problema para que cada vez que instale el paquete el JSP se vuelva a compilar, entonces modifique su paquete de la siguiente manera:

1. Añada dos reglas de filtrado al principio de su filter.xml (en META-INF/vault/filter.xml)
   

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

2. Luego incluya dos carpetas vacías /var/classes/org/apache/jsp/apps y /var/classes/apps en su paquete zip. Esto es para que cuando instale el paquete, todos los archivos de clase bajo estas rutas se borren. En consecuencia, hace que todos los JSP y archivos Java de su aplicación en el directorio /apps de su paquete los vuelva a compilar Apache Sling.

Se aplica a

CQ5.2, CQ5.3 sin corrección 30517

Información adicional

Este problema se debe a la forma en que Apache Sling evalúa si debe compilar un determinado archivo JSP o Java.

La fecha jcr:lastModified del script se compara con la fecha jcr:lastModified del archivo de clase existente.

Si la última fecha modificada del script es más reciente que la del archivo de clase, se vuelve a compilar. De lo contrario, no se vuelve a compilar.

Cuando empaqueta un zip que contiene archivos jsp, entonces algunos JSP pueden tener marcas de tiempo más antiguas que los archivos de clase bajo /var/classes.