|
Page Edited :
SLING :
Updating the Sling Launcher
Updating the Sling Launcher has been edited by Felix Meschberger (Jan 13, 2009). Content:Updating the Sling LauncherStatus: DRAFT 1 Problem ScopeA 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 IdeaWe 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:
3 Launcher JAR updateSince 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:
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 updateThe launcher JAR must have two basic features:
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 a Notifiable instances. The Notifiable.stopped() is called if the framework has been stopped. The Notifiable.updated(File) is called if the framework has been stopped for it to be restarted, where the file argument may be the new launcher JAR to use. The Notifiable.stopped method enables the main class or servlet to react to the situation that the framework has gone and take appropriate actions. The Notifiable.updated(File) method enables the main class or servlet to drop the framework and classloader and restart the framework in a new class loader with a potentially new launcher JAR. 5 PrototypeI have prepared a prototype of this concept in my white board at http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/launchpad The launchpad/base module creates two artifacts: The primary artifact is included with the final application. The secondary artifact is the actual launcher JAR file. 6.1 Primary ArtifactThe primary artifact contains three elements:
/** * Creates an URLClassLoader from a _launcher JAR_ file in the given * slingHome directory and loads and returns the launcher class * identified by the launcherClassName. * @param launcherClassName The fully qualified name of a class * implementing the Launcher interface. This class must have * a public constructor taking no arguments. * @param slingHome The value to be used as ${slingHome}. This may * be null in which case the sling folder in the current working * directory is assumed. If this name is empty, the current working * directory is assumed to be used as ${slingHome}. * @return the Launcher instance loaded from the newly created classloader * @throws NullPointerException if launcherClassName is null * @throws IllegalArgumentException if the launcherClassName cannot be * instantiated. The cause of the failure is contained as the cause * of the exception. */ public static Launcher loadLauncher(String launcherClassName, String slingHome); /** * Tries to remove as many traces of class loaded by the framework from * the Java VM as possible. Most notably the following traces are removed: * <ul> * <li>JavaBeans property caches * <li>Java Logging caches * </ul> * <p> * This method must be called when the notifier is called. */ public static void cleanupVM();
// set sling home for the framework public void setSlingHome(String slingHome); // set the Notifiable to be informed on stop/update public void setNotifiable(Notifiable notifiable); // sets command line arguments, mainly used by the main class public void setCommandLine(String[] args); // starts the framework public void start(); // stops the framework // this method only returns when the framework has actually been stopped. // this method may be used by the main class or servlet to initiate a // shutdown of the framework public void stop(); 6.2 Secondary ArtifactThe secondary artifact is just what is the launchpad/base artifact today. The extension is just the support for the new API defined in the primary artifact. This secondary artifact is included as the launcher JAR in the final application. |
Unsubscribe or edit your notifications preferences
