Framework update is unstable
----------------------------
Key: SLING-1095
URL: https://issues.apache.org/jira/browse/SLING-1095
Project: Sling
Issue Type: Improvement
Components: Launchpad Launcher
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.
