[jira] Closed: (SLING-1095) Framework update is unstable

["Felix Meschberger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger closed SLING-1095.
------------------------------------


Released.

> Framework update is unstable
> ----------------------------
>
>                 Key: SLING-1095
>                 URL: https://issues.apache.org/jira/browse/SLING-1095
>             Project: Sling
>          Issue Type: Improvement
>          Components: Launchpad
>    Affects Versions: Launchpad Base 2.0.4
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: Launchpad Base 2.1.0
>
>
> The Framework API specifies that calling Bundle.update(InputStream) should update the framework.
> In the Sling launcher we implemented this functionality by storing the framework.jar file in the filesystem (along the sling.properties file) and creating a class loader from that jar file to launch the framework and thus Sling. This works perfectly and has the added benefit to make sure the framework is really isolated from the environment (something which is not always guaranteed by certain servlet containers).
> The problem with the current implementation is two-fold:
> (1) The URLClassLoader loads the jar file using a JAR URL, which - by default - uses caching. As a consequence replacing the existing jar file with a new one of the same name causes resources loaded through the class loader (Class.getResource[AsStream], ClassLoader.getResource[AsStream]) to actually come from the old JAR file instead of the new one.
> (2) Replacing a JAR file which has been used by a class loader is not always possible. Particularly on Windows systems, the files which are still opened by a process cannot be removed and thus cannot be replaced. On Unix systems, the situation is different because removing a file does not really delete it but just removes the directory entry and thus enables to create a new file with the same name.
> Both problems can be fixed for good by using generational jar file names:
>    * On startup all jar file generations are checked and all files except the most recent one is removed. The most recent
>        jar file is renamed to the base name also used on initial startup
>    * On system bundle update a new generation jar file is created and the new framework is launched from the new
>        generation jar file.
> The drawback of this solution is, that a live update is not possible because the fixed part launcher has to be replaced. This is less of a problem in a servlet container environment (using the Sling web app launcher) because in that situation the web can simply be replaced.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.