JSPs don't recompile after a code package installation
JSPs don't always recompile after a code package installation
When you install a CQ5 package containing a new version of our /apps code (with .jsp or .java files contained), not all of the JSP code is recompiled after installing the package.
To resolve this issue for a single install, do the following:
- Log in to
http://<host>:<port>/crxas admin (where <host> is the host name or IP address of your CQ5 server and <port> is the port number).
- Open the CRX Explorer tool.
- Delete the nodes under
To resolve this issue so that every time you install the package the JSP is recompiled, then modify your package as follows:
- Add two filter rules at the beginning of your filter.xml (in META-INF/vault/filter.xml)
<workspaceFilter version="1.0"> <filter root="/var/classes/org/apache/jsp/apps" /> <filter root="/var/classes/apps" /> ...
- Then include two empty folders
/var/classes/appsin your package zip. This is so that when you install the package, then all class files under these paths are deleted. Consequently, it causes all of your application JSPs and Java files in the /apps directory of your package to be recompiled by Apache Sling.
CQ5.2, CQ5.3 without hot fix 30517
This issue is due to the way in which Apache Sling evaluates whether to compile a given JSP or Java file.
The jcr:lastModified date of the script is compared to the existing class file'sjcr:lastModified date.
If the last modified date of the script is newer than the class file's, then it is recompiled. Otherwise, it is not recompiled.
When you package a zip containing jsp files, then some JSPs may have older timestamps than the class files under /var/classes.
Do not use this workaround with CQ5.4. If you are having this issue in CQ5.4, then submit a daycare ticket and request
AEM6 has web console plug-in to clear the compiled classes regardless of where and how they are stored which can be used during code deployment http://<host>:<port>/system/console/slingjsp