Return-Path: X-Original-To: apmail-sling-commits-archive@www.apache.org Delivered-To: apmail-sling-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6A314CC73 for ; Tue, 22 May 2012 08:26:49 +0000 (UTC) Received: (qmail 8204 invoked by uid 500); 22 May 2012 08:26:48 -0000 Delivered-To: apmail-sling-commits-archive@sling.apache.org Received: (qmail 8153 invoked by uid 500); 22 May 2012 08:26:48 -0000 Mailing-List: contact commits-help@sling.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@sling.apache.org Delivered-To: mailing list commits@sling.apache.org Received: (qmail 8136 invoked by uid 99); 22 May 2012 08:26:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 May 2012 08:26:48 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 May 2012 08:26:44 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 600172388C73 for ; Tue, 22 May 2012 08:25:45 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r818658 [3/23] - in /websites/staging/sling/trunk/content: ./ tutorials-how-tos/ Date: Tue, 22 May 2012 08:25:36 -0000 To: commits@sling.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120522082545.600172388C73@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Modified: websites/staging/sling/trunk/content/architecture.html ============================================================================== --- websites/staging/sling/trunk/content/architecture.html (original) +++ websites/staging/sling/trunk/content/architecture.html Tue May 22 08:25:32 2012 @@ -82,195 +82,63 @@ Home

Architecture

-

-

Architecture of Sling

+

Architecture of Sling

The following is a short list of high-lights of Sling:

    -
  • *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
    • -
  • --- To implement content based Web applications with Sling, an API has -been defined, this extends the Servlet API and provides more functionality -to work on the content.
    • -
  • *#Request Processing
    • -
  • --- Sling takes a unique approach to handling requests in that a request -URL is first resolved to a resource, then based on the resource (and only -the resource) it selects the actual servlet or script to handle the -request.
    • -
  • *#Resources
    • -
  • --- The central mantra of Sling is the Resource, which represents the -resource addressed by any request URL. It is the resource that is first -resolved when handling a request. Based on the resource, a first servlet or -script is then accessed to actually handle the request.
    • -
  • *#Servlets and Scripts
    • -
  • --- Servlets and Scripts are handled uniformly in that they are -represented as resources themselves and are accessible by a resource path.
    • -
  • *#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.
    • +
  • 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 --- To implement content based Web applications with Sling, an API has been defined, this extends the Servlet API and provides more functionality to work on the content.
    • +
  • #Request Processing --- Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
    • +
  • #Resources --- The central mantra of Sling is the Resource, which represents the resource addressed by any request URL. It is the resource that is first resolved when handling a request. Based on the resource, a first servlet or script is then accessed to actually handle the request.
    • +
  • #Servlets and Scripts --- Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
    • +
  • #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 highlights.

-

OSGi

-

OSGi - is a consortium that has developed a specification to build modular and -extensible applications. This offers [various benefits|http://www.osgi.org/About/WhyOSGi] -. We deal mainly 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 that -extend the functionality of the OSGi Framework.

-

+

OSGi is a consortium that has developed a specification to build modular and extensible applications. This offers [various benefits|http://www.osgi.org/About/WhyOSGi]. We deal mainly 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 that extend the functionality of the OSGi Framework.

OSGi Framework

-

The OSGi Framework is made up of three layers -- Module, Lifecycle, and -Services -- that define how extensible applications are built and deployed. -The responsibilities of the layers are:

+

The OSGi Framework is made up of three layers -- Module, Lifecycle, and Services -- that 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. This describes a registry for -services, which may be shared.
    • +
  • 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. This 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:

+

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 -needed for the Sling application to perform logging.
    • -
  • Http Service --- Sling leverages the OSGi Http Service to hook into a -servlet container to provide the Web Application Framework mechanism.
    • -
  • Configuration Admin Service --- To simplify configuration of services -in Sling, the OSGi Configuration 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 that may be created using the Configuration Admin Service. -These meta type descriptions are used by configuration management agents to -present to user interface to manage the configurations.
    • -
  • Event Admin Service --- Sling uses the OSGi EventAdmin service to -dispatch events when scheduling tasks.
    • -
  • Declarative Services --- One of the most important (beside the Log -Service) services used by Sling is the Declarative Services Specification. -This specification defines how to declaratively create components and -services to have the Declarative Services runtime actually manage the -lifecycle, configuration and references of components.
    • +
  • 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 needed for the Sling application to perform logging.
    • +
  • Http Service --- Sling leverages the OSGi Http Service to hook into a servlet container to provide the Web Application Framework mechanism.
    • +
  • Configuration Admin Service --- To simplify configuration of services in Sling, the OSGi Configuration 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 that may be created using the Configuration Admin Service. These meta type descriptions are used by configuration management agents to present to user interface to manage the configurations.
    • +
  • Event Admin Service --- Sling uses the OSGi EventAdmin service to dispatch events when scheduling tasks.
    • +
  • Declarative Services --- One of the most important (beside the Log Service) services used by Sling is the Declarative Services Specification. This specification defines how to declaratively create components and services to have the Declarative 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 - page for more information.

-

+

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 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 - page for more information.

-

+

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 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) 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 - page for more information.

-

+

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 page for more information.

Servlets and Scripts

-

Scripts are usually provided 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) 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 - page for more information.

-

+

Scripts are usually provided 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 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 - page for information on how to do this.

-

See The Sling Launchpad - for more information.

+

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 page for information on how to do this.

+

See The Sling Launchpad for more information.

- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000 + Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project Modified: websites/staging/sling/trunk/content/assembly.html ============================================================================== --- websites/staging/sling/trunk/content/assembly.html (original) +++ websites/staging/sling/trunk/content/assembly.html Tue May 22 08:25:32 2012 @@ -82,152 +82,48 @@ Home

Assembly

-

-

Assembly: Bundling Bundles

+

Assembly: Bundling Bundles

{panel} -The Assembly concept grew out of a need to bundle together a set of OSGi -Bundles to deploy applications. The concept has been developped before the -OSGi Deployment Package Service Specification has been published in the -Release 4.1 Compendium Services Specification. It will have to be discussed -whether the Assembly concept is dropped in favor of the Deplyoment Package -Service. +The Assembly concept grew out of a need to bundle together a set of OSGi Bundles to deploy applications. The concept has been developped before the OSGi Deployment Package Service Specification has been published in the Release 4.1 Compendium Services Specification. It will have to be discussed whether the Assembly concept is dropped in favor of the Deplyoment Package Service. {panel}

-

Introduction

-

This chapter discusses the units of deployment as well as the units of -functionality. The following contents is based on the Module and Service -specifications of the OSGi Service Platform Core Specification, Release 4 -but enhances functionality for ease of use and in terms of best practices.

-

The term Units of Deployment describes the idea of packaging up -functionality implemented by Java Classes into modules, so called -Bundles. For bigger and more complicated applications the fine grained -modularity of Bundles may be to complicated, so this chapter proposes an -extension called Assembly. The goal of the Assembly specification -presented below is to provide functionality to delivery a collection of -bundles belonging together.

-

The term Units of Functionality describes the idea of providing services -implemented by Java Classes, so called Services. A Service is an -abstraction and does not actually prescribe the implementation of specific -interfaces. Instead the OSGi specification states how functionality may be -provided to clients by registering objects implementing interfaces defining -the functionality in terms of a Java API.

-

+

This chapter discusses the units of deployment as well as the units of functionality. The following contents is based on the Module and Service specifications of the OSGi Service Platform Core Specification, Release 4 but enhances functionality for ease of use and in terms of best practices.

+

The term Units of Deployment describes the idea of packaging up functionality implemented by Java Classes into modules, so called Bundles. For bigger and more complicated applications the fine grained modularity of Bundles may be to complicated, so this chapter proposes an extension called Assembly. The goal of the Assembly specification presented below is to provide functionality to delivery a collection of bundles belonging together.

+

The term Units of Functionality describes the idea of providing services implemented by Java Classes, so called Services. A Service is an abstraction and does not actually prescribe the implementation of specific interfaces. Instead the OSGi specification states how functionality may be provided to clients by registering objects implementing interfaces defining the functionality in terms of a Java API.

Bundles

-

The core unit of deployment is the Bundle. The OSGi core specification -defines a Bundle to be a Java Archive (JAR) file whose manifest - the -META-INF/MANIFEST.MF file - contains specific headers identifying the -bundle. Most manifest headers are optional with defined default values - -only the Bundle-SymbolicName header is actually required and the -Bundle-ManifestVersion header should be set to 2 to identify the -bundle to be a R4 bundle. Other information defined in the manifest is the -bundle version, the list of packages exported - provided to other bundles - -and imported - used and required to be provided by other bundles. See -chapter 3.2.1 Bundle Manifest Header of the OSGi Service Platform Core -Specification for a complete list of the defined bundle manifest headers.

-

Bundles may be installed, updated , started, stopped and removed in an OSGi -framework individually.

-

+

The core unit of deployment is the Bundle. The OSGi core specification defines a Bundle to be a Java Archive (JAR) file whose manifest - the META-INF/MANIFEST.MF file - contains specific headers identifying the bundle. Most manifest headers are optional with defined default values - only the Bundle-SymbolicName header is actually required and the Bundle-ManifestVersion header should be set to 2 to identify the bundle to be a R4 bundle. Other information defined in the manifest is the bundle version, the list of packages exported - provided to other bundles - and imported - used and required to be provided by other bundles. See chapter 3.2.1 Bundle Manifest Header of the OSGi Service Platform Core Specification for a complete list of the defined bundle manifest headers.

+

Bundles may be installed, updated , started, stopped and removed in an OSGi framework individually.

Assemblies

-

For the deployment of bigger systems, the number of bundles may increase -very quickly. To ease the management of products consisting of multiple -bundles, this chapter introduces the Assembly. An Assembly is simply a -collection of bundles deployed together. An Assembly - like a Bundle - is a -JAR file whose manifest contains specific headers. In fact, an Assembly is -just a standard bundle, with additional functionality.

-

Assemblies are managed by the Assembly Manager which itself is a bundle -installed into the framework.

-

+

For the deployment of bigger systems, the number of bundles may increase very quickly. To ease the management of products consisting of multiple bundles, this chapter introduces the Assembly. An Assembly is simply a collection of bundles deployed together. An Assembly - like a Bundle - is a JAR file whose manifest contains specific headers. In fact, an Assembly is just a standard bundle, with additional functionality.

+

Assemblies are managed by the Assembly Manager which itself is a bundle installed into the framework.

Assembly manifest headers

-

As an Assembly is a standard Bundle, all the defined Bundle manifest -headers may be specified. In addition, for the Assembly Manager to -recognize an assembly and for the OSGi Bundle Repository to support -dependency resolution, the following manifest headers are defined. All -headers are optional with documented default values except where noted.

+

As an Assembly is a standard Bundle, all the defined Bundle manifest headers may be specified. In addition, for the Assembly Manager to recognize an assembly and for the OSGi Bundle Repository to support dependency resolution, the following manifest headers are defined. All headers are optional with documented default values except where noted.

    -
  • Assembly-Bundles - The list of bundles contained in this assembly. See -below for the definition of the syntax of this header. This header is -required. The presence of this headers identifies an Assembly to the -Assembly Manager.
    • -
  • Assembly-BundleRepository - A comma-separated list of URLs pointing to -OSGi Bundle Repository descriptors. These bundle repositories will be used -to install bundles listed in the Assembly-Bundles header. This header -is optional with not default value.
    • +
  • Assembly-Bundles - The list of bundles contained in this assembly. See below for the definition of the syntax of this header. This header is required. The presence of this headers identifies an Assembly to the Assembly Manager.
    • +
  • Assembly-BundleRepository - A comma-separated list of URLs pointing to OSGi Bundle Repository descriptors. These bundle repositories will be used to install bundles listed in the Assembly-Bundles header. This header is optional with not default value.
-

Assembly Lifecycle

An Assembly, like all bundles, may be in any of the defined bundle states:

    -
  • Installed - The Assembly bundle has been installed into the system but -not yet resolved. The Assembly Manager will try to install all bundles -listed in the Assembly-Bundles header. The start levels of the bundles -will be set according to the startlevel parameter. The bundles will not -be started. If installation of one or more of the bundles fails, Assembly -Manager logs an error message.
    • -
  • Resolved - The Assembly bundle is resolved, that is all imported -packages are wired into the framework. The Assembly Manager does not -handle this state change, rather the installed bundles will be resolved by -the framework either automatically after installation or when started -later.
    • -
  • Started - The Assembly bundle has been started by calling the -Bundle.start() method. The Assembly Manager will start all newly -installed and resolved bundles. Depending on the start level set on the -bundle(s) and the current system start level, the bundles will only be -permanently marked to start while actually starting the bundles may be -delayed until the system enters the respective start level. If any bundle -fails to start, an error message is logged.
    • -
  • Stopped - The Assembly bundle has been stopped by calling the -Bundle.stop() method. All bundles belong to the Assembly and linked to -the Assembly are also stopped.
    • -
  • Unresolved - The Assembly bundle has been unresolved by the system for -any reason, possibly any missing dependencies. Assembly bundles entering -this state are ignored by the Assembly Manager.
    • -
  • Uninstalled - The Assembly bundle is being uninstalled by calling the -Bundle.uninstall() method. The Assembly Manager will (try to) -uninstall all bundles listed in the Assembly-Bundles header.
    • -
  • Updated - The Assembly bundle will update all bundles installed -previously according to the Assembly-Bundles header. If this header -omits any bundle listed in the previous bundle version, the respective -bundle is uninstalled from the system. If a bundle is already installed -with the correct version, the installed bundle is not touched (It may -though be uninstalled together with the Assembly Bundle if the Assembly -Bundle is uninstalled).
    • +
  • Installed - The Assembly bundle has been installed into the system but not yet resolved. The Assembly Manager will try to install all bundles listed in the Assembly-Bundles header. The start levels of the bundles will be set according to the startlevel parameter. The bundles will not be started. If installation of one or more of the bundles fails, Assembly Manager logs an error message.
    • +
  • Resolved - The Assembly bundle is resolved, that is all imported packages are wired into the framework. The Assembly Manager does not handle this state change, rather the installed bundles will be resolved by the framework either automatically after installation or when started later.
    • +
  • Started - The Assembly bundle has been started by calling the Bundle.start() method. The Assembly Manager will start all newly installed and resolved bundles. Depending on the start level set on the bundle(s) and the current system start level, the bundles will only be permanently marked to start while actually starting the bundles may be delayed until the system enters the respective start level. If any bundle fails to start, an error message is logged.
    • +
  • Stopped - The Assembly bundle has been stopped by calling the Bundle.stop() method. All bundles belong to the Assembly and linked to the Assembly are also stopped.
    • +
  • Unresolved - The Assembly bundle has been unresolved by the system for any reason, possibly any missing dependencies. Assembly bundles entering this state are ignored by the Assembly Manager.
    • +
  • Uninstalled - The Assembly bundle is being uninstalled by calling the Bundle.uninstall() method. The Assembly Manager will (try to) uninstall all bundles listed in the Assembly-Bundles header.
    • +
  • Updated - The Assembly bundle will update all bundles installed previously according to the Assembly-Bundles header. If this header omits any bundle listed in the previous bundle version, the respective bundle is uninstalled from the system. If a bundle is already installed with the correct version, the installed bundle is not touched (It may though be uninstalled together with the Assembly Bundle if the Assembly Bundle is uninstalled).
-

Bundles referenced by multiple Assembly Bundles

-

It is conceivable, that bundles are listed in the Assembly-Bundles -header of more than one Assembly Bundle. If this is the case, the following -collision resolution takes place:

+

It is conceivable, that bundles are listed in the Assembly-Bundles header of more than one Assembly Bundle. If this is the case, the following collision resolution takes place:

    -
  • If the version of the bundle installed by the first Assembly bundle -handled matches the version specification of any later Assembly Bundle, the -installed bundle is not touched. Otherwise, if the later Assembly Bundle -lists a version specification, which is acceptable for the first Assembly -Bundle, the installed bundle is updated to the required version. If the -version specifications may not be matched one way or the other, the later -Assembly Bundle fails to install.
    • -
  • If the bundle is installed with a defined start level, the later -Assembly Bundle will not overwrite the already set start level. If the -start level has not been set yet it is set to the specified start level.
    • -
  • Bundles installed through Assembly Bundles remain installed as long as -there is at least one Assembly Bundle listing the bundle in the -Assembly-Bundles header. As soon as there is no referring Assembly -Bundle anymore, the bundle is uninstalled.
    • -
  • Bundles not referred to by any Assembly Bundle are ignored by the -Assembly Manager.
    • -
  • Bundles installed through the Assembly Manager may be updated and/or -uninstalled independently from their defining Assembly Bundle. If a bundle -has been installed it will be reinstalled the next time the Assembly Bundle -enters the installed state. If a bundle has been updated, it is not -touched by the Assembly Manager as long as the updated version matches -the version specification of the Assembly Bundle.
    • +
  • If the version of the bundle installed by the first Assembly bundle handled matches the version specification of any later Assembly Bundle, the installed bundle is not touched. Otherwise, if the later Assembly Bundle lists a version specification, which is acceptable for the first Assembly Bundle, the installed bundle is updated to the required version. If the version specifications may not be matched one way or the other, the later Assembly Bundle fails to install.
    • +
  • If the bundle is installed with a defined start level, the later Assembly Bundle will not overwrite the already set start level. If the start level has not been set yet it is set to the specified start level.
    • +
  • Bundles installed through Assembly Bundles remain installed as long as there is at least one Assembly Bundle listing the bundle in the Assembly-Bundles header. As soon as there is no referring Assembly Bundle anymore, the bundle is uninstalled.
    • +
  • Bundles not referred to by any Assembly Bundle are ignored by the Assembly Manager.
    • +
  • Bundles installed through the Assembly Manager may be updated and/or uninstalled independently from their defining Assembly Bundle. If a bundle has been installed it will be reinstalled the next time the Assembly Bundle enters the installed state. If a bundle has been updated, it is not touched by the Assembly Manager as long as the updated version matches the version specification of the Assembly Bundle.
-

Bundle Installation

-

When an Assembly is installed into the framework, the Assembly Manager -checks to see whether the Assembly needs to be deployed. This is done by -checking the bundles listed in the Assembly-Bundles header whether they -are installed or not. All bundles not installed will be installed and -started if requested so.

+

When an Assembly is installed into the framework, the Assembly Manager checks to see whether the Assembly needs to be deployed. This is done by checking the bundles listed in the Assembly-Bundles header whether they are installed or not. All bundles not installed will be installed and started if requested so.

The following BNF defines the syntax =Assembly-Bundles= header value:

Assembly-Bundles = Bundle { "," Bundle } .
 Bundle = Symbolic-Name { ";" Parameter } .
@@ -236,97 +132,40 @@ started if requested so.
-

To control the selection and installation of bundles, the following -parameters may be used:

+

To control the selection and installation of bundles, the following parameters may be used:

    -
  • version - The version of the bundle to install. This is a version range -specification as per chapter 3.2.5 Version Ranges of the OSGi core -specification. When this parameter is declared as a single version - eg. -1.2.3 - it is interpreted as the version range ~[1.2.3, ∞~). The -default value is ~[0.0.0,∞~) to install the most recent version of -the bundle available.
    • -
  • startlevel - The start level to set for the bundle. This may be any -positive integer value. Default value is undefined to use the current -initial bundle start level of the framework.
    • -
  • entry - The path of the Assembly Bundle entry providing the data to be -installed.
    • -
  • linked - Defines whether the bundle should be started and stopped -together with the Assembly to which the bundle belongs. Default value is -true.
    • +
  • version - The version of the bundle to install. This is a version range specification as per chapter 3.2.5 Version Ranges of the OSGi core specification. When this parameter is declared as a single version - eg. 1.2.3 - it is interpreted as the version range ~[1.2.3, ∞~). The default value is ~[0.0.0,∞~) to install the most recent version of the bundle available.
    • +
  • startlevel - The start level to set for the bundle. This may be any positive integer value. Default value is undefined to use the current initial bundle start level of the framework.
    • +
  • entry - The path of the Assembly Bundle entry providing the data to be installed.
    • +
  • linked - Defines whether the bundle should be started and stopped together with the Assembly to which the bundle belongs. Default value is true.
-

If resolving the bundles results in more bundles to be downloaded from the -bundle repository to resolve the dependency, these bundles are always -automatically started and assigned a startlevel which is smaller than the -smallest startlevel of any of the bundles listed.

-

+

If resolving the bundles results in more bundles to be downloaded from the bundle repository to resolve the dependency, these bundles are always automatically started and assigned a startlevel which is smaller than the smallest startlevel of any of the bundles listed.

Bundle Location

-

Generally bundles to be installed with an Assembly Bundle are retrieved -from an OSGi Bundle Repository. The Assembly-BundleRepository header -may list additional URLs which will be temporarily used to resovle the -bundles. Otherwise the system default bundle repositories will be used -only.

-

If a bundle is defined in the Assembly-Bundles header with an entry -parameter, the respective entry is first looked for in the Assembly Bundle. -If the entry exists, it is used as the bundle source to install. If no -entry parameter is present for a declared bundle or the entry is -missing, the OSGi Bundle Repository is used.

+

Generally bundles to be installed with an Assembly Bundle are retrieved from an OSGi Bundle Repository. The Assembly-BundleRepository header may list additional URLs which will be temporarily used to resovle the bundles. Otherwise the system default bundle repositories will be used only.

+

If a bundle is defined in the Assembly-Bundles header with an entry parameter, the respective entry is first looked for in the Assembly Bundle. If the entry exists, it is used as the bundle source to install. If no entry parameter is present for a declared bundle or the entry is missing, the OSGi Bundle Repository is used.

Restrictions when packaging bundles with the Assembly:

    -
  • Dependency Resolution - Any missing dependencies of the bundles to be -installed will not be resolved. That is, if the bundles fail to resolve, -the Assembly fails to install.
    • -
  • version Parameter - The version parameter of the bundle -installation declaration is ignored because any JAR file whose name matches -the bundle symbolic name to be installed, is installed.
    • +
  • Dependency Resolution - Any missing dependencies of the bundles to be installed will not be resolved. That is, if the bundles fail to resolve, the Assembly fails to install.
    • +
  • version Parameter - The version parameter of the bundle installation declaration is ignored because any JAR file whose name matches the bundle symbolic name to be installed, is installed.
-

If the Assembly-BundleRepository header contains a comma-separated list -of URL to OSGi Bundle Repository descriptors and the OSGi Bundle Repository -Service is available in the framework, the bundles declared in the -Assembly-Bundles header are resolved through the OSGi Bundle Repository -Service using the URL from the Assembly-BundleRepository header.

-

If the bundles declare any dependencies, which may not be resolved by -bundles already installed in the framework or by any of the bundles to be -installed, the OSGi Bundle Repository is used to try to resolve these -missing dependencies. If this resolution succeeds, installation of the -Assembly succeeds. Any bundles not declared in the Assembly but installed -due to this dependency resolution will not be assumed to belong to the -Assembly. Hence, these bundles will not be uninstalled (or updated) if the -Assembly is uninstalled (or updated).

+

If the Assembly-BundleRepository header contains a comma-separated list of URL to OSGi Bundle Repository descriptors and the OSGi Bundle Repository Service is available in the framework, the bundles declared in the Assembly-Bundles header are resolved through the OSGi Bundle Repository Service using the URL from the Assembly-BundleRepository header.

+

If the bundles declare any dependencies, which may not be resolved by bundles already installed in the framework or by any of the bundles to be installed, the OSGi Bundle Repository is used to try to resolve these missing dependencies. If this resolution succeeds, installation of the Assembly succeeds. Any bundles not declared in the Assembly but installed due to this dependency resolution will not be assumed to belong to the Assembly. Hence, these bundles will not be uninstalled (or updated) if the Assembly is uninstalled (or updated).

    -
  • Example - Assume the Assembly-Bundles header is set to -org.apache.sling.sample1;entry=path.jar,org.apache.sling.sample2. The -bundle org.apache.sling.sample1 is then installed from the Assembly -Bundle entry path.jar, while the bundle org.apache.sling.sample2 is -resolved in the OSGi Bundle Repository.
    • +
  • Example - Assume the Assembly-Bundles header is set to org.apache.sling.sample1;entry=path.jar,org.apache.sling.sample2. The bundle org.apache.sling.sample1 is then installed from the Assembly Bundle entry path.jar, while the bundle org.apache.sling.sample2 is resolved in the OSGi Bundle Repository.
-

Best Practices

-

Size of Bundles

-

There is no fixed formula to calculate the best size for a bundle: It all -depends on the contents and the intentions of the bundle and its -programmer. The following list provides some hints:

+

There is no fixed formula to calculate the best size for a bundle: It all depends on the contents and the intentions of the bundle and its programmer. The following list provides some hints:

  • For ease of development follow the idea of One Bundle - One Project
    • -
  • Don't pack too much into a bundle but do not pack a single class into -a bundle (unless you have a very good reason of course :-) )
    • -
  • Do not mix and match everything into a bundle. Rather bundle things -together which belong together, for example create separate bundles for a -HTTP Client implementation and DB support classes
    • -
  • Use similar heuristics to decide on the contents of a bundle as you -would for the contents of a plain old JAR file.
    • +
  • Don't pack too much into a bundle but do not pack a single class into a bundle (unless you have a very good reason of course :-) )
    • +
  • Do not mix and match everything into a bundle. Rather bundle things together which belong together, for example create separate bundles for a HTTP Client implementation and DB support classes
    • +
  • Use similar heuristics to decide on the contents of a bundle as you would for the contents of a plain old JAR file.
-

Nomen est Omen

-

The symbolic name of a bundle should reflect its contents. A bundle should -generally only contain a single subtree in the virtual package tree. The -symbolic name of the bundle should be the root package contained within. -For example, consider a bundle containing the packages -org.apache.sling.sample, org.apache.sling.sample.impl, -org.apache.sling.more. The bundle would the be named -org.apache.sling.sample.

+

The symbolic name of a bundle should reflect its contents. A bundle should generally only contain a single subtree in the virtual package tree. The symbolic name of the bundle should be the root package contained within. For example, consider a bundle containing the packages org.apache.sling.sample, org.apache.sling.sample.impl, org.apache.sling.more. The bundle would the be named org.apache.sling.sample.

- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000 + Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project Added: websites/staging/sling/trunk/content/authentication-actors.html ============================================================================== --- websites/staging/sling/trunk/content/authentication-actors.html (added) +++ websites/staging/sling/trunk/content/authentication-actors.html Tue May 22 08:25:32 2012 @@ -0,0 +1,138 @@ + + + + + Apache Sling - Authentication - Actors + + + + + +
+ +
+ + Apache + +
+
+ +
+

Documentation
+Getting Started
+The Sling Engine
+Development
+Bundles
+Tutorials & How-Tos
+Configuration
+Wiki
+FAQ
+Site Map

+

API Docs
+Sling 6
+Sling 5
+

+

Project info
+Downloads
+License
+Contributing
+News
+Links
+Project Information
+Issue Tracker
+Browse Source Repository
+Security
+

+

Sponsorship
+Thanks
+Become a Sponsor
+Buy Stuff
+

+ +
+ +
+
+ Home +
+

Authentication - Actors

+

Actors

+

The authentication process involves a number of actors contributing to the concepts, the API and the particular implementations.

+

OSGi Http Service Specification

+

The main support for authentication is defined by the OSGi Http Service specification. This specification defines how an OSGi application can register servlets and resources to build web applications. As part of the servlet and/or resource registration a HttpContext may be provided, which allows for additional support.

+

The main method of interest to the authentication process is the handleSecurity method. This is called by the OSGi Http Service implementation before the registered servlet is called. Its intent is to authenticate the request and to provide authentication information for the request object: the authentication type and the remote user name.

+

The Sling Commons Auth bundle provides the AuthenticationSupport service which may be used to the implement the HttpContext.handleSecurity method.

+

Sling Engine

+

The Sling Engine implements the main entry point into the Sling system by means of the SlingMainServlet. This servlet is registered with the OSGi Http Service and provides a custom HttpContext whose handleSecurity method is implemented by the AuthenticationSupport service.

+

When the request hits the service method of the Sling Main Servlet, the resource resolver provided by the AuthenticationSupport service is retrieved from the request attributes and used as the resource resolver for the request.

+

That's all there is for the Sling Engine to do with respect to authentication.

+

Sling Commons Auth

+

The support for authenticating client requests is implemented in the Sling Commons Auth bundle. As such this bundle provides three areas of support

+
    +
  • AuthenticationHandler service interface. This is implemented by services providing functionality to extract credentials from HTTP requests.
    • +
  • Authenticator service interface. This is implemented by the SlingAuthenticator class in the Commons Auth bundle and provides applications with entry points to login and logout.
    • +
  • AuthenticationSupport service interface. This is implemented by the SlingAuthenticator class in the Commons Auth bundle and allows applications registering with the OSGi HTTP Service to make use of the Sling authentication infrastructure.
    • +
+

JCR Repository

+

The actual process of logging into the repository and provided a Session is implementation dependent. In the case of Jackrabbit extensibility is provided by configuration of the Jackrabbit repository by means of an interface and two helper classes:

+
    +
  • LoginModule -- The interface to be implemented to provide login processing plugins
    • +
  • AbstractLoginModule -- A an abstract base class implementation of the LoginModule interface.
    • +
  • DefaultLoginModule -- The default implementation of the AbstractLoginModule provided by Jackabbit. This login module takes SimpleCredentials and uses the repository to lookup the users, validate the credentials and providing the Principal representing the user towards the repository.
    • +
+

The Sling Jackrabbit Embedded Repository bundle provides additional plugin interfaces to extend the login process dynamically using OSGi services. To this avail the bundle configures a LoginModule with the provided default Jackrabbit configuration supporting these plugins:

+
    +
  • LoginModulePlugin -- The main service interface. Plugins must implement this interface to be able to extend the login process. See for example the Sling OpenID authentication handler, which implements this interface to support OpenID authentication.
    • +
  • AuthenticationPlugin -- Helper interface for the LoginModulePlugin.
    • +
+

Sling Applications

+

Sling Applications requiring authenticed requests should not care about how authentication is implemented. To support such functionality the Authenticator service is provided with two methods:

+
    +
  • +

    login -- allows the application to ensure requests are authenticated. This involves selecting an AuthenticationHandler to request credentials for authentication.

    +
    • +
  • +

    logout -- allows the application to forget about any authentication. This involves selecting an AuthenticationHandler to forget about credentials in the request.

    +
    • +
+

Sling Applications should never directly use any knowledge of any authentication handler or directly call into an authentication handler. This will certainly break the application and cause unexpected behaviour.

+

{info} +If you want to know whether a request is authenticated or not, you can inspect the result of the HttpServletRequest.getAuthType method: If this method returns null the request is not authenticated. +{info}

+
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000 +
+
+ Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project + logo are trademarks of The Apache Software Foundation. All other marks mentioned + may be trademarks or registered trademarks of their respective owners. +
+
+ + Added: websites/staging/sling/trunk/content/authentication-authenticationhandler.html ============================================================================== --- websites/staging/sling/trunk/content/authentication-authenticationhandler.html (added) +++ websites/staging/sling/trunk/content/authentication-authenticationhandler.html Tue May 22 08:25:32 2012 @@ -0,0 +1,127 @@ + + + + + Apache Sling - Authentication - AuthenticationHandler + + + + + +
+ +
+ + Apache + +
+
+ +
+

Documentation
+Getting Started
+The Sling Engine
+Development
+Bundles
+Tutorials & How-Tos
+Configuration
+Wiki
+FAQ
+Site Map

+

API Docs
+Sling 6
+Sling 5
+

+

Project info
+Downloads
+License
+Contributing
+News
+Links
+Project Information
+Issue Tracker
+Browse Source Repository
+Security
+

+

Sponsorship
+Thanks
+Become a Sponsor
+Buy Stuff
+

+ +
+ +
+
+ Home +
+

Authentication - AuthenticationHandler

+

AuthenticationHandler

+

The AuthenticationHandler interface defines the service API which may be implemented by authentication handlers registered as OSGi services.

+

AuthenticationHandler services have a single required service registration property which is used to identify requests to which the AuthenticationHandler service is applicable:

+

| path | One or more (array or vector) string values indicating the request URLs to which the AuthenticationHandler is applicable. | +| authtype | The authentication type implemented by this handler. This is a string value property and should be the same as will be used as the authentication type of the AuthenticationInfo object provided by the extractCredentials method. If this property is set, the requestCredentials method of the authentication handler is only called if the sling:authRequestLogin request parameter is either not set or is set to the same value as the authtype of the handler. This property is optional. If not set, the requestCredentials method is always called regardless of the value of the sling:authRequestLogin request parameter. |

+

Each path may be an absolute URL, an URL with just the host/port and path or just a plain absolute path:

+

| URL part | Scheme | Host/Port | Path | +| Absolute URL | must match | must match | request URL path is prefixed with the path | +| Host/Port with Path | ignored | must match | request URL path is prefixed with the path | +| Path | ignored | ignored | request URL path is prefixed with the path |

+

When looking for an AuthenticationHandler the authentication handler is selected whose path is the longest match on the request URL. If the service is registered with Scheme and Host/Port, these must exactly match for the service to be eligible. If multiple AuthenticationHandler services are registered with the same length matching path, the handler with the higher service ranking is selected{footnote}Service ranking is defined by the OSGi Core Specification as follows: If multiple qualifying service interfaces exist, a service with the highest service.ranking number, or when equal to the lowest service.id, determines which service object is returned by the Framework.{footnote}.

+

The value of path service registration property value triggering the call to any of the AuthenticationHandler methods is available as the path request attribute (for the time of the method call only). If the service is registered with multiple path values, the value of the path request attribute may be used to implement specific handling.

+

Implementations provided by Sling

+ +

Sample implementations

+

HTTP Basic Authentication Handler

+
    +
  • extractCredentials -- Get user name and password from the Authorization HTTP header
    • +
  • requestCredentials -- Send a 401/UNAUTHORIZED status with WWW-Authenticate response header setting the Realm
    • +
  • dropCredentials -- Send a 401/UNAUTHORIZED status with WWW-Authenticate response header setting the Realm
    • +
+

Interestingly the dropCredentials method is implemented in the same way as the requestCredentials method. The reason for this is, that HTTP Basic authentication does not have a notion of login and logout. Rather the request is accompanied with an Authorization header or not. The contents of this header is usually cached by the client browser. So logout is actually simulated by sending a 401/UNAUTHORIZED status thus causing the client browser to clear the cache and ask for user name and password.

+

Form Based Authentication Handler

+
    +
  • extractCredentials -- Get user name and password with the help of a special cookie (note, that of course the cookie should not contain this data, but refer to it in an internal store of the authentication handler). If the cookie is not set, check for specific login parameters to setup the cookie.
    • +
  • requestCredentials -- Send the login form for the user to provide the login parameters.
    • +
  • dropCredentials -- Clear the authentication cookie and internal store.
    • +
+

///Footnotes Go Here///

+
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000 +
+
+ Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project + logo are trademarks of The Apache Software Foundation. All other marks mentioned + may be trademarks or registered trademarks of their respective owners. +
+
+ +