The Sling Launchpad Launcher can be used to embed the OSGi Framework startup in your own Java application. This functionality is implemented in the Sling Launchpad Base project. This project has the following features:
This page is about the internal details of the Sling Launchpad Base module. To get an outside overview of the Sling Launchpad you might want to refer to The Sling Launchpad page.
The Launcher is based on three parts:
The external part uses the bridging part to create the class loader into which the internal part is loaded. The bidirectional communication between the external and internal part is implement based on two interfaces:
Launcherinterface is implemented by a class in the internal part which is loaded through the bridge class loader. This interface allows setting, starting and stopping of the framework.
Notifiableinterface is implemented by a class in the external part which instance is handed to the
Launcherinstance. This interface allows the internal part to communicate back to the external part, most notably to indicate that the framework has been stopped from within or that the framework has been updated and must be restarted.
The bridging part is provided in the
|Launcher||The interface implemented by the internal class matching the external class being called to start/stop the framework.|
|Loader|| Helper class to find the launchpad library and to create the |
|Notifiable||The interface implemented in the external part and handed over to the internal part.|
|SharedConstants||Constants naming various properties and classes.|
The main class from the internal class directly used is
Sling which instantiated to start the OSGi Framework. This class is responsible for setting up the environment to finally start the OSGi Framework:
SlingFelix class extends the Apache Felix
Felix class which is the actual OSGi framework implementation. We extend the class to be able to notify the
Notifiable implementation and update the OSGi framework from within the OSGi framework by updating the system bundle.
The external part is comprised of a main class started from the environment -- main class of the Java applicaction or the servlet deployed in the servlet container -- and a corresponding delegate class located inside of the launchpad base library. This delegate class is instantiated by the
Loader loading from the
The standalone Java Application makes use of three classes:
|Main|| This is the main class whose |
|MainDelegate|| This class is loaded by the |
|ControlListener|| This class is used by the |
At the moment these classes are not directly suitable to be embedded in an existing application (or custom application launcher framework) unless that embedding prepares command line arguments in a
String and calls the
Main.main method. To allow for custom embeddings or extensions, the work distributions between the three classes should be refactored.
To embedd the Sling Launcher in an application, the
Main class is extended from. To manage the launcher, the following API is available:
| || Instantiates the Main class with the given configuration properties. These are properties which are used directly as overwrites to the configurations in the |
| ||Before starting the application for the first time, this method can be called to handle any control command action.|
| || Starts the Sling Application using the provided configuration properties as overwrites. Also these properties (or the |
| || Stops the application started by the |
By using control actions, the Sling Launcher may open or connect to a control port to communicate. The
doControlAction() method together with the
sling.control.socket properties is able to setup this communication.
sling.control.socket is either a normal port number, in which case the connection is opened on the
localhost interface (usually 127.0.0.1). Otheriwse, it may also be a value of the form host:port where host is the name or IP address of the interface to connect to and port is the port number. For security reasons it is suggested to not use an interface which is available remotely. So the default of
localhost is usually the best choice.
sling.control.action takes either of three values:
| || Starts a server socket as specified by the |
| || The |
| || The |
When calling the Main class through the JVM startup the
Main.main(String args) methods is called which reads the command line arguments and converts them into a
Map<String, String> suitable for the constructore as follows:
|Command Line Argument||Properties Entry|
|start||sling.control.action = "start"|
|status||sling.control.action = "status"|
|stop||sling.control.action = "stop"|
|-c slinghome||sling.home = slinghome|
|-l loglevel||org.apache.sling.commons.log.level = loglevel|
|-f logfile||org.apache.sling.commons.log.file = logfile|
|-a address||This command line argument is not supported yet and thus ignored|
|-p port||org.osgi.service.http.port = port|
|-j [ host ":" ] port||sling.control.socket = [ host ":" ] port|
|-h||This command line option is handled directly and not converted into the map|
The web application makes use of 5 classes:
|SlingServlet|| This is the servlet registered in the |
|SlingSessionListener|| This -- somewhat inappropriately named -- class is registered as a listener by the Sling |
|SlingBridge|| Simple extension of the |
|SlingHttpSessionListenerDelegate|| This class is loaded by the |
|SlingServletDelegate|| This class is loaded by the |
At the moment these classes, particularly the
SlingServlet class, are not particularly well suited to be extended by a servlet slightly modifying the launcher.