Re: [CONF] Apache Sling Website > Architecture

[Justin Edelson <ju...@gmail.com>]

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.

Justin

On 6/8/10 9:50 PM, confluence@apache.org 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>
> 

Re: [CONF] Apache Sling Website > Architecture

[Felix Meschberger <fm...@gmail.com>]

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, confluence@apache.org 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>
>>
> 
>