You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Dan Klco (JIRA)" <ji...@apache.org> on 2016/08/19 16:26:21 UTC
[jira] [Created] (SLING-5980) Duplicate Script Cache Clearing
Functionality
Dan Klco created SLING-5980:
-------------------------------
Summary: Duplicate Script Cache Clearing Functionality
Key: SLING-5980
URL: https://issues.apache.org/jira/browse/SLING-5980
Project: Sling
Issue Type: Bug
Affects Versions: File System ClassLoader 1.0.2, Scripting JSP 2.1.8
Reporter: Dan Klco
Currently, there are two ways to clear the scripting classloader cache, one in the [JSP Scripting Console]((https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java) (http://localhost:8080/system/console/slingjsp) and on in the [File System ClassLoader Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java) (http://localhost:8080/system/console/fsclassloader)
Unfortunately these two consoles perform slightly differently:
* JSP Scripting Console - only clears out the JSPs and also destroys the JSP Runtime Context
* FS ClassLoader - Clears out all script compiled files including JSP, Sightly, etc
I'm thinking about doing the following:
* Removing the JSP Scripting Console
* Adding a method into the ClassLoaderWriter for scripting providers to register and unregister a listener for classloader cache flushes
Consolidating the functionality will make the use of the console clearer. With the callback, the JSP Script Engine (or any other scripting engine for that matter) could react to a cache clear and perform the appropriate actions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)