[CONF] Apache Sling: Updating the Sling Launcher (page created)

[confluence]

Page Created : SLING : Updating the Sling Launcher Updating the Sling Launcher has been created by Felix Meschberger (Jan 10, 2009). Content: Updating the Sling Launcher Status: DRAFT Created: 10. Januar 2009 Author: fmeschbe Updated: – 1 Problem Scope 2 Idea 3 Launcher JAR update 4 Launcher support for stop and update 5 Prototype 1 Problem Scope A Sling instance is launched by the Sling launcher, which is a single JAR (standalone Java Application) or WAR (Web Application) file. This file cannot currently be updated without physical access to the system, stopping the system, replacing the file and restarting the system. It would be a good thing, if we could use existing administration API such as the Felix Web Console or the Felix (Remote) Shell to update this launcher. This concept is about how we could slightly restructure the launcher to enable just this functionality. 2 Idea We have a single JAR file, which contains the OSGi framework (Apache Felix), the OSGi core libraries and the actual launcher for the OSGi framework. This single JAR file the launcher JAR is contained as a JAR file in either the standalone Java Application JAR or the Web Application WAR file. The Standalone Java Application JAR File contains a single main class, which reads the command line and instantiates the actual launcher in the launcher JAR and waits for its termination. The Web Application WAR File contains a single servlet, which instantiates the actual launcher servlet in the launcher JAR and reacts to its termination. Both the main class and the servlet are very tiny and have the following tasks: Read the initial configuration for the launcher. This initial configuration becomes the overwrite properties for the sling properties used as the framework properties. The initial configuraiton is read as follows: The main class uses the command line arguments and the system properties for the initial configuration The servlet uses the servlet and servlet context init-params for the initial configuration After getting the initial configuration, the main class will just have the framework started. The servlet will create and initialize a servlet provided by the launcher JAR, which also sets up the OSGi HttpService bridge. After starting the framework through the launcher, the main class does nothing more. The servlet will forward the service requests to the launched servlet. To initiate an external shutdown, the main class or servlet terminate the launcher: The main class just calls the stop method and waits for its termination The servlet calls destroy() on the launched internal servlet During the lifetime of Sling, the framework may be stopped from within by calling the stop or update methods. To inform the main class or servlet of this situation, the launcher takes to Runnable instances: One is called by the launcher when the framework has been stopped. The other is called if the framework has been stopped, but should be restarted again. These Runnable instances are only called when the framework has completely been shut down. If instructed by having the Runnable being called, which is notified of a required restart, the main class or servlet will start from scratch at the first step. 3 Launcher JAR update Since the launcher JAR is a single JAR file, it may be updated. But it must also be possible to make sure the new code is actually being used after restart. To implement this requirement the main class or servlet follow this algorithm: Place or replace the launcher JAR file in the filesystem inside $ Unknown macro: {sling.home} Create an URLClassLoader with this JAR file and the class loader of the main class or servlet as the parent class loader The main class uses reflection to instantiate and start the launcher. The main servlet uses reflection only to instantiate the launcher servlet. After that the normal servlet API is used for further interaction. After the launcher terminates either by the stop or update method being called on the system bundle or by being requested from the main class or servlet, the class loader is just dropped and thus given to the garbage collector. It may be, that there will have to be some cleanup for the garbage collector to be operational. Notable areas are the Java VM JavaBeans cache and any caches of the Java Logging API. 4 Launcher support for stop and update The launcher JAR must have two basic features: Know when the framework is stopped by the stop or update method being called on the system bundle Take the appropriate measure after the framework has been stopped To implement these two features, the launcher JAR overwrites the stop and update methods of the Felix class, which implements the system bundle. The update(InputStream) method is overwritten to take the new launcher JAR file and place it such, that it can be used to restart. All method overwrites, start a separate thread which waits for the framework to terminate. When the framework has been terminated, the main class or servlet is notified. The main class or servlet provide the launcher with two Runnable instances: stopNotifier and updateNotifier. The stopNotifier is called if the framework has been stopped. The updateNotifier is called if the framework has been stopped for it to be restarted. The stopNotifier Runnable enables the main class or servlet to react to the situation that the framework has gone and take appropriate actions. The updateNotifier Runable enables the main class or servlet to drop the framework and classloader and restart the framework in a new class loader with a potentiall new launcher JAR. 5 Prototype I will be creating a prototype implementation in my whiteboard

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences