コードパッケージのインストール後に JSP が常に再コンパイルされない
/apps コード(.jsp または .java ファイルを含む)の新しいバージョンを含む CQ5 パッケージをインストールした場合、JSP コードのすべてがパッケージのインストール後に再コンパイルされるわけではありません。
解決策
単一インストールのこの問題を解決するには、次を行います。
- 管理者として
http://<host>:<port>/crx
にログインします(<host> が CQ5 サーバーのホスト名または IP アドレスであり、<port> がポート番号です)。 - CRX Explorer ツールを開きます。
/var/classes/org/apache/jsp/apps/
の下のノードを削除します。
JSP が再コンパイルされるパッケージをインストールするたびにこの問題を解決するには、次の手順に従って、パッケージを変更します。
- filter.xml(META-INF/vault/filter.xml 内にある)の最初にある 2 つのフィルタルールを追加します。
<workspaceFilter version="1.0"> <filter root="/var/classes/org/apache/jsp/apps" /> <filter root="/var/classes/apps" /> ...
- 次に、パッケージ zip 内に 2 つの空フォルダー
/var/classes/org/apache/jsp/apps
および/var/classes/apps
を含めます。これにより、パッケージをインストールするときに、これらのパスの下にあるすべてのクラスファイルが削除されます。したがって、パッケージの /apps ディレクトリにあるすべてのアプリケーション JSP ファイルと Java ファイルが、Apache Sling によって再コンパイルされるようになります。
適用対象
CQ5.2、ホットフィックス 30517
がない CQ5.3
追加情報
この問題は、特定の JSP または Java ファイルをコンパイルするかどうかを Apache Sling で評価する方法が原因で発生します。
スクリプトの jcr:lastModified の日付が、既存のクラスファイルの jcr:lastModified の日付と比較されます。
スクリプトの最終更新日がクラスファイルより新しい場合は、再コンパイルされます。それ以外の場合は、再コンパイルされません。
jsp ファイルを含む zip をパッケージ化すると、/var/classes にあるクラスファイル以前のタイムスタンプを含めることができます。
CQ5.4 でこの回避策を使用しないでください。CQ5.4 に問題がある場合は、Daycare チケットを送信して要求してください。
AEM6 には、保存されている場所と方法に関係なく、http://<host>:<port>/system/console/slingjsp のコードデプロイメント中に使用できる、コンパイル済みクラスをクリアするための Web コンソールプラグインがあります。
アカウントにログイン