[
https://issues.apache.org/jira/browse/SLING-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved SLING-1095.
--------------------------------------
Resolution: Fixed
Resolving this issue after having deployed a SNAPSHOT
> 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.0.6
>
>
> 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.
