[
https://issues.apache.org/jira/browse/SLING-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775367#action_12775367
]
Felix Meschberger commented on SLING-1095:
------------------------------------------
Implemented this fix in Rev. 834413:
The Loader class is not a utility class anymore but a regular class, which must
be instantiated to for use. The constructor throws an IllegalArgumentException
if the Sling home folder cannot be created or is not a directory. This helps
with error handling during startup.
The Main and SlingServlet classes are adapted to the new Loader class and
properly handle startup failure due to failure to instantiate the Loader class.
The Loader now maintains multiple revisions of the launcher JAR files provided
for installation or update. When an update is taking place during run time a
new launcher JAR file is created which bears the time-stamp in its name. Over
time multiple time-stamped launcher JAR files may exist in the sling home
directory. On startup these files are cleaned up and only the most recent
version is kept (with the timestamp removed from the name).
By using timestamped versions of the launcher JAR files, we circumvent the
caching issues (the files are always "new" and uncached resources are always
used) and file removal issues on Windows platforms (files are only removed on
startup).
> 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.
