Hi, On 09.06.2010 03:56, Justin Edelson wrote: > Does anyone have any objections to me moving this page up a level? It's > IMHO buried underneath "The Sling Engine", when it actually doesn't talk > about the Engine at all.
+1 Regards Felix > > Justin > > On 6/8/10 9:50 PM, [email protected] wrote: >> >> >> >> Architecture >> <https://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture> >> >> >> Page *edited* by Justin Edelson >> <https://cwiki.apache.org/confluence/display/~justinedelson> >> >> *Comment:* cleaning up outdated HttpService info >> >> >> Changes (6) >> >> ... >> h2. Launchpad >> >> Sling may be launched as a standalone application using the Sling >> Application or as a Web Application running inside any Servlet API 2.4 >> or newer Servlet Container. >> >> The Sling Application is a standalone Java Application which is really >> small: Just the main class and some glue classes. The OSGi framework as >> well as the OSGi API libraries are packaged as a JAR file, which is >> loaded through a custom classloader. This enables to update the >> framework and/or OSGi API libraries from within Sling by updating the >> system bundle. >> >> The Sling Servlet is equally small as the Sling Application. In addition >> to the Sling servlet, the Equinox HTTP Servlet is contained in the Sling >> web application, which provides the glue between the servlet container >> and the OSGi framework. >> The Sling Servlet is equally small as the Sling Application. It uses the >> Felix {{HttpService}} bridge as the glue between the servlet container >> and the OSGi framework. >> >> As we have seen, Sling may be launched as a standalone Java Application >> or as a Web Application inside any compliant Servlet Container. To hide >> the differences of the launching mechanism, Sling internally registers a >> Servlet with an OSGi {{HttpService}}. Depending on the launch method, >> the following {{HttpService}} implementations are used: >> As we have seen, Sling may be launched as a standalone Java Application >> or as a Web Application inside any compliant Servlet Container. To hide >> the differences of the launching mechanism, Sling internally registers a >> Servlet with an OSGi {{HttpService}}. Regardless of how Sling is >> launched, the Felix implementation of the OSGi {{HttpService}} >> specification is used. When Sling is launched as a standalone Java >> Application, Felix HttpService uses an embedded version of the Jetty >> servlet container. When Sling is launched as a Web Application, the >> Felix HttpService Bridge is used. >> >> Optionally, PAX Web's implementation of HttpService can be used when >> Sling is launched as a standalone Java Application. See the [Maven >> Launchpad Plugin] page for information on how to do this. >> >> * *PAX Web Service* - If Sling is launched as a standalone Java >> Application, the PAX Web Service bundle is used as the implementation of >> the OSGi {{HttpService}}. >> * *Equinox HTTP Servlet* - If Sling is launched as a Web Application, >> the [Equinox HTTP Servlet|http://www.eclipse.org/equinox/server] is used >> as the OSGi {{HttpService}} implementation to link the HTTP Servlet into >> the Servlet Container through the Sling Servlet. >> >> >> See [Launch Sling] for more information. >> >> >> Full Content >> >> >> Architecture of Sling >> >> The following is a short list of high-lights of Sling: >> >> * *OSGi <#Architecture-OSGi>* — The Sling application is built as a >> series of OSGi bundles and makes heavy use of a number of OSGi >> core and compendium services >> * *Sling API <#Architecture-SlingAPI>* — To implement Content based >> Web Applications with Sling, an API has been defined, which >> extends the Servlet API and provides more functionality to work on >> the content >> * *Request Processing <#Architecture-RequestProcessing>* — Sling >> takes a unique approach to handling requests in that a request URL >> is first resolved to a resource and only based on the resource >> then select the actual servlet or script to handle the request. >> * *Resources <#Architecture-Resources>* — The central mantra of >> Sling is the *Resource*, which represents the resource addressed >> by any request URL. It is the resource, which is first resolved >> when handling a request. Based on the resource, a first servlet or >> script is then looked up to actually handle the request. >> * *Servlets and Scripts <#Architecture-ServletsandScripts>* — >> Servlets and Scripts are handled uniformly in that they are >> represented as resources themselves and are accessible by a >> resource path. >> * *Launchpad <#Architecture-Launchpad>* — Sling uses a very thin >> launcher to integrate with an existing servlet container launching >> Sling as a Web Application or providing a main class to represent >> a standalone Java Application. >> >> The following sections elaborate on each of these high-lights. >> >> >> OSGi >> >> OSGi <http://www.osgi.org> is a consortium which developped a >> specification to build modular and extensible applications. We are >> mainly dealing with two parts of the specifications: The Core >> Specification which defines the OSGi Framework and Core Services and the >> Compendium Services Specification, which defines a host of Services, >> which extend the functionality of the OSGi Framework. >> >> >> OSGi Framework >> >> The OSGi Framework is made up of three layers – Module, Lifecycle, and >> Services – which define how extensible applications are built and >> deployed. The responsibilities of the layers are: >> >> * *Module* — Defines how a module, or a /Bundle/ in OSGi speak, is >> defined. Basically a bundle is just a plain old JAR file, whose >> manifest file has some defined entries. These entries identify the >> bundle with a symbolic name, a version, and more. In addition >> there are headers which define what a bundle provides – >> Export-Package – and what a bundle requires to be operative – >> Import-Package and Require-Bundle. >> * *Lifecycle* — The lifecycle layer defines the states a bundle may >> be in and describes the state changes. By providing a class, which >> implements the BundleActivator interface and which is named in the >> Bundle-Activator manifest header, a bundle may hook into the >> lifecycle process when the bundle is started and stopped. >> * *Services* — For the application to be able to interact, the OSGi >> Core Specification defines the service layer, which describes a >> registry for services, which may be shared. >> >> >> Compendium Services >> >> Based on the OSGi Framework specification, the Compendium Services >> specification defines a (growing) number of extension services, which >> may be used by applications for various tasks. Of these Compendium >> Services, Sling is using just a small number: >> >> * *Log Service* — Sling comes with its own implementation of the >> OSGi Log Service specification. The respective bundle not only >> provides this implementation, it also exports the SLF4J, Log4J and >> Commons Logging APIs for Sling application to perform logging. >> * *Http Service* — To hook into a servlet container to provide the >> Web Application Framework mechanism Sling is leveraging the OSGi >> Http Service. >> * *Configuration Admin Service* — To simplify configuration of >> services in Sling, the OSGi Configuraiton Admin service is used. >> This provides a uniform API to configure services and to build >> configuration management agents. >> * *Metatype Service* — The OSGi Metatype Service defines a way to >> describe the data types. Sling uses this service to describe the >> configurations which may be created using the Configuration Admin >> Service. These meta type descriptions are used by configuraiton >> management agents to present to user interface to manage the >> configurations. >> * *Event Admin Service* — To dispatch events for scheduling of >> tasks, Sling is using the OSGi EventAdmin service. >> * *Declarative Services* — One of the most important (besides the >> Log Service) services used by Sling is the Declarative Services >> Specification. This specification defines how to declaratively >> create components and services and have the Declaratvie Services >> runtime actually manage the lifecycle, configuration and >> references of components. >> >> >> Sling API >> >> The Sling API is an extension to the Servlet API which provides more >> functionality to interact with the Sling framework and also to extend >> Sling itself and to implement Sling applications. >> >> See the Sling API </confluence/display/SLINGxSITE/Sling+API> page for >> more information. >> >> >> Request Processing >> >> Traditional Web Application framework emply more or less elaborate >> methods to select a Servlet or Controller based on the request URL, >> which in turn tries to load some data (usually from a database) to act >> upon and finally to render the result somehow. >> >> Sling turns this processing around in that it places the data to act >> upon at the center and consequently uses the request URL to first >> resolve the data to process. This data is internally represented as an >> instance of the Resource interface. Based on this resource as well as >> the request method and more properties of the request URL a script or >> servlet is then selected to handle the request. >> >> See the Servlets </confluence/display/SLINGxSITE/Servlets> page for more >> information. >> >> >> Resources >> >> The Resource is one of the central parts of Sling. Extending from JCR's >> /Everything is Content/, Sling assumes /Everthing is a Resource/. Thus >> Sling is maintaining a virtual tree of resources, which is a merger of >> the actual contents in the JCR Repository and resources provided by so >> called resource providers. >> >> Each resource has a path by which it is addressed in the resource tree, >> a resource type and some resource metadata (such as file size, last >> modification time). It is important to understand, that a Resource >> instance actually is only a handle to the actual data. By virtue of the >> adaptTo(Class<Type>) method, a resource may be coerced into another data >> type, which may then be used while processing the request. Examples of >> data types are javax.jcr.Node and java.io.InputStream. >> >> See the Resources </confluence/display/SLINGxSITE/Resources> page for >> more information. >> >> >> Servlets and Scripts >> >> Scripts are usually provides as content in a JCR repository. But since >> Sling is using a resource tree, a script actually is represented as a >> Resource and may be provided from within a Bundle (by virtue of the >> bundle resource provider) or even from the platform file system (by >> virtue of the file system resource provider). >> >> Accessing scripts in the resource tree, allows for a very easy to >> understand mapping from resource type to some script path. >> >> Having found the script resource, we still need access to the >> appropriate script language implementation to evaluate the script. To >> this avail, Sling is making use of the Resource.adaptTo(Class<Type>) >> method: If a script language implementation is available for the >> extension of the script name an adaptor for the script resource can be >> found, which handles the evaluation of the script. >> >> Besides scripting languages, such as ECMAScript, Groovy, JSP, Sling also >> supports regular servlets. To be able to use servlets for request >> processing, such servlets must be registered as OSGi services for the >> javax.servlet.Servlet interface and provide a number of service >> registration properties, which are used to use the servlets. In fact >> servlets thus registered as OSGi services are mapped into the resource >> tree by means of a servlet resource provider. This resource provider >> mapps the servlets into the resource tree using the service registration >> properties to build one or more resource paths for the servlet. >> >> As a result of mapping servlets into the resource tree and the >> possibility to adapt resource to an adaptor data type, scripts and >> servlets may be handled completely transparently: The servlet resolver >> just looks for a resource matching the resource type and adapts the >> resource found to javax.jcr.Servlet. If the resource happens to be >> provided by a servlet resource provider, the adapter is of course the >> servlet itself. If the resource happens to be a script, the adapter is a >> servlet facade which internally calls the script language implementation >> to evaluate the script. >> >> See the Servlet Resolution >> </confluence/display/SLINGxSITE/Servlet+Resolution> page for more >> information. >> >> >> Launchpad >> >> Sling may be launched as a standalone application using the Sling >> Application or as a Web Application running inside any Servlet API 2.4 >> or newer Servlet Container. >> >> The Sling Application is a standalone Java Application which is really >> small: Just the main class and some glue classes. The OSGi framework as >> well as the OSGi API libraries are packaged as a JAR file, which is >> loaded through a custom classloader. This enables to update the >> framework and/or OSGi API libraries from within Sling by updating the >> system bundle. >> >> The Sling Servlet is equally small as the Sling Application. It uses the >> Felix HttpService bridge as the glue between the servlet container and >> the OSGi framework. >> >> As we have seen, Sling may be launched as a standalone Java Application >> or as a Web Application inside any compliant Servlet Container. To hide >> the differences of the launching mechanism, Sling internally registers a >> Servlet with an OSGi HttpService. Regardless of how Sling is launched, >> the Felix implementation of the OSGi HttpService specification is used. >> When Sling is launched as a standalone Java Application, Felix >> HttpService uses an embedded version of the Jetty servlet container. >> When Sling is launched as a Web Application, the Felix HttpService >> Bridge is used. >> >> Optionally, PAX Web's implementation of HttpService can be used when >> Sling is launched as a standalone Java Application. See the Maven >> Launchpad Plugin </confluence/display/SLINGxSITE/Maven+Launchpad+Plugin> >> page for information on how to do this. >> >> See Launch Sling </confluence/display/SLINGxSITE/Launch+Sling> for more >> information. >> >> Change Notification Preferences >> <https://cwiki.apache.org/confluence/users/viewnotifications.action> >> View Online >> <https://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture> | >> View Changes >> <https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=76156&revisedVersion=9&originalVersion=8> >> | Add Comment >> <https://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture?showComments=true&showCommentArea=true#addcomment> >> > >
