You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/09/03 09:23:32 UTC
[jira] Created: (SLING-1095) Framework update is unstable
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.
[jira] Resolved: (SLING-1095) Framework update is unstable
Posted by "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 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.
[jira] Commented: (SLING-1095) Framework update is unstable
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (SLING-1095) Framework update is unstable
Posted by "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.