Architecture of Sling
Sling is an implementation of the Component API consisting of several modules. The core architectural features of Sling are as follows:
- The modules are implemented as OSGi Bundles
- The functionality of Sling is glued together based on the OSGi Service Layer using Declarative Services to easily manage service registrations, configuration and refererence tracking
- Configuration is managed using the OSGi Configuration Admin Service
Sling may be launched as a standalone application using the Sling Application or as a Web Application running inside any Servlet API 2.3 or newer Servlet Container.
The Sling Application is a standalone Java Application which is relatively small. It contains some helper classes to launch Apache Felix as the OSGi Framework. Of course the Apache Felix Framework library as well as the OSGi Core and Compendium libraries are part of the Sling Application. These three parts are actually the only ones, which may not be exchanged through the OSGi Lifecycle Layer. To enable bootstrapping, the Sling Application also contains three bundles, which are by default deployed into the started framework: The log bundle, the assembly bundle and the Apache Felix Bundle Repository bundle. As these bundles are deployed using the OSGi Lifecycle Layer, they may of course be updated if need be.
The Sling Servlet is an extension of the Sling Application in that it contains a simple Servlet calling into the Sling Application Launcher to launch Sling inside the Web Application. Additionally, the Sling Servlet provides the hook for the integration of the OSGi Http Service running inside the framework to attach to the Servlet Container in which the Sling Servlet is running.
Servlet Container support
As we have seen, Sling may be launched as a standalone Java Application or as a Web Application inside any compliant Servlet Container. To blur the differences of the launching mechanism, Sling internally registers a Servlet with a OSGi HttpService. Depending on the launch method, the following HttpService implementations are used:
- Apache Felix http.jetty
If Sling is launched as a standalone Java Application, the Apache Felix http.jetty bundle is used as the implementation of the OSGi HttpService. In this case the http.jetty bundle exports the Serlvet API interfaces used by Sling.
- Equinox HTTP Servlet
If Sling is launched as a Web Application, the Equinox HTTP Servlet is used as the OSGi HttpService implementation in conjunction with sling-servlet-bridge bundle to link the HTTP Servlet into the Servlet Container through the Sling Servlet.
The Sling launcher (standalone or web application) only contains core classes and bundles to get a first launch. After the launch, the bundle activator of the sling-assembly bundle will look at the framework properties to try to install further bundles and thus bootstrap Sling.
See Initial Provisioning and Startup for a detailed description of this process.
Bundles of Sling
Sling consists of the following bundles:
Implements the OSGi Log Service specification and exports Log4J, SLF4J and Apache Commons Logging for legacy applications. Internally, all logging goes to NLog4J. See also the page on logging.
Bundle and application installation support. This bundle provides a service to install bundles from an OSGi Bundle Repository. Additionally it supports an application "bundling" functionality called Assembly. See Assemblies for more details on this bundling.
Exports the API classes of the Component API.
- Implements the JCR Repository Content mapping functionality. Additionally implements support for initial load of content out of bundles into the JCR Repository as well as defining Node Types.
The core implementation of the Sling Component Framework. This bundle implements the core request processing infrastructure of Sling. See also the page on Content Loading and Nodetype Support.
- Basic framework to support scripting languages in Sling.
- Support for JSP Scripting where the JSP scripts are located in the JCR Repository and will be compiled into classes stored in the JCR Repository. The JSP classes will then be loaded from the JCR Repository using the Jackrabbit Repository Classloader.
Provides a simple basic JSP Tag Library to easily access the Sling internals like the ContentManager.
Provides the Classloader to load JSP (and other scripting) classes from the JCR Repository. This bundle is used by the sling-scripting-jsp bundle to load the compiled JSP classes.
Provides the JSP Compiler to the sling-scripting-jsp bundle. As the name implies it is based on the Jasper JSP compiler: Jasper 5.5.20 has been modified to allow writing JSP classes (and intermediate Java sources) to the JSR Repository instead of the platform filesystem. This bundle also contains the Eclipse 3.2 Java Compiler used to compile the Java sources into JSP class files.
Exports the JCR and Jackrabbit API as well as the jackrabbit-jcr-commons library. In addition this bundle provides the basis to implement session pooling.
Contains the Jackrabbit core enabling to start Jackrabbit Repository instances embedded in Sling. This bundle uses the sling-jackrabbit-api bundle to provide pooled sessions to the embedded repository instances.
Contains support to access an existing Jackrabbit Repository instance running in the same Java VM (e.g. the Jackrabbit web app) or in a foreign Java VM. Again, this bundle uses the sling-jackrabbit-api bundle to provide pooled sessions to the embedded repository instances. sling-servlet-bridge: A very simple bundle bridging the Eclipse implementation of the OSGi HTTP Service specification to the Servlet Container into which the Sling Servlet is deployed. See above for more details.
- Simple Servlet based management GUI to manage a running Sling instance. This tool may be used to manage bundle lifecycle, check the state of the system and manage configurations through the Configuration Admin Service.
Standard Components provided by Sling. Currently this bundle contains Content and Component implementations to support simple access nodes of type nt:folder, nt:file and nt:resource.