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:22 UTC
[jira] [Updated] (SLING-5980) Duplicate Script Cache Clearing
Functionality
[ https://issues.apache.org/jira/browse/SLING-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Klco updated SLING-5980:
----------------------------
Description:
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.
was:
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.
> Duplicate Script Cache Clearing Functionality
> ---------------------------------------------
>
> Key: SLING-5980
> URL: https://issues.apache.org/jira/browse/SLING-5980
> Project: Sling
> Issue Type: Bug
> Affects Versions: Scripting JSP 2.1.8, File System ClassLoader 1.0.2
> Reporter: Dan Klco
> Assignee: 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)