You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by fm...@apache.org on 2012/05/22 10:25:22 UTC
svn commit: r1341347 [2/16] - in /sling/site/trunk: ./ content/
content/tutorials-how-tos/
Modified: sling/site/trunk/content/apache-sling.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/apache-sling.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/apache-sling.mdtext (original)
+++ sling/site/trunk/content/apache-sling.mdtext Tue May 22 08:25:18 2012
@@ -1,176 +1,102 @@
Title: Apache Sling
-<a name="ApacheSling-ApacheSling-BringingBacktheFun"></a>
+
# Apache Sling - Bringing Back the Fun
-{tm}Apache Sling{tm} is an innovative web framework that is intended to
-bring back the fun to web development.
+{tm}Apache Sling{tm} is an innovative web framework that is intended to bring back the fun to web development.
-Discussions about Sling happen on our mailing lists, see the [Project Information](project-information.html)
- page for more info.
+Discussions about Sling happen on our mailing lists, see the [Project Information]({{ refs.project-information.path }}) page for more info.
-<a name="ApacheSling-ApacheSlinginfivebulletspoints"></a>
# Apache Sling in five bullets points
* REST based web framework
* Content-driven, using a JCR content repository
* Powered by OSGi
-* Scripting inside, multiple languages (JSP, server-side javascript, Scala,
-etc.)
+* Scripting inside, multiple languages (JSP, server-side javascript, Scala, etc.)
* Apache Open Source project
-<a name="ApacheSling-ApacheSlinginahundredwords"></a>
# Apache Sling in a hundred words
-Apache Sling is a web framework that uses a [Java Content Repository](http://en.wikipedia.org/wiki/JSR-170)
-, such as [Apache Jackrabbit|http://jackrabbit.apache.org/]
-, to store and manage content.
-
-Sling applications use either scripts or Java servlets, selected based on
-simple name conventions, to process HTTP requests in a RESTful way.
-
-The embedded [Apache Felix](http://felix.apache.org/)
- OSGi framework and console provide a dynamic runtime environment, where
-code and content bundles can be loaded, unloaded and reconfigured at
-runtime.
-
-As the first web framework dedicated to [JSR-170](http://jcp.org/en/jsr/detail?id=170)
- Java Content Repositories, Sling makes it very simple to implement simple
-applications, while providing an enterprise-level framework for more
-complex applications.
+Apache Sling is a web framework that uses a [Java Content Repository]({{ refs.http://en.wikipedia.org/wiki/JSR-170.path }}), such as [Apache Jackrabbit|http://jackrabbit.apache.org/], to store and manage content.
+
+Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.
+
+The embedded [Apache Felix]({{ refs.http://felix.apache.org/.path }}) OSGi framework and console provide a dynamic runtime environment, where code and content bundles can be loaded, unloaded and reconfigured at runtime.
+
+As the first web framework dedicated to [JSR-170]({{ refs.http://jcp.org/en/jsr/detail?id=170.path }}) Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications.
-<a name="ApacheSling-News"></a>
## News
-{excerpt-include:News|nopanel=true}
-* [all news...](news.html)
+{{ refs.news.headers.excerpt }}
+* [all news...]({{ refs.news.path }})
-<a name="ApacheSling-History"></a>
## History
-Sling started as an internal project at [Day Software](http://www.day.com)
-, and entered the Apache Incubator in September 2007. As of June, 17th,
-2009 Apache Sling is a top level project of the Apache Software Foundation.
+Sling started as an internal project at [Day Software]({{ refs.http://www.day.com.path }}), and entered the Apache Incubator in September 2007. As of June, 17th, 2009 Apache Sling is a top level project of the Apache Software Foundation.
-The name "Sling" has been proposed by Roy Fielding who explained it like
-this:
+The name "Sling" has been proposed by Roy Fielding who explained it like this:
{quote}
-\[The name is\](the-name-is\.html)
- Biblical in nature. The story of David: the weapon he uses to slay the
-giant Goliath is a sling. Hence, our David's \[David Nuescheler, CTO of
-Day Software\] favorite weapon.
+\[The name is\]({{ refs.the-name-is.path }}) Biblical in nature. The story of David: the weapon he uses to slay the giant Goliath is a sling. Hence, our David's \[David Nuescheler, CTO of Day Software\] favorite weapon.
It is also the simplest device for delivering content very fast.
{quote}
-<a name="ApacheSling-WhousesSling?"></a>
## Who uses Sling?
-See [Who is using Sling](http://cwiki.apache.org/SLING/who-is-using-sling-.html)
- on our public wiki.
+See [Who is using Sling]({{ refs.http://cwiki.apache.org/SLING/who-is-using-sling-.html.path }}) on our public wiki.
-<a name="ApacheSling-Gettingstarted"></a>
## Getting started
-If you prefer doing rather than reading, please proceed to [Discover Sling in 15 minutes](discover-sling-in-15-minutes.html)
- or read through the recommended links in the [Getting Started]
- section, where you can quickly get started on your own instance of Sling.
+If you prefer doing rather than reading, please proceed to [Discover Sling in 15 minutes]({{ refs.discover-sling-in-15-minutes.path }}) or read through the recommended links in the [Getting Started] section, where you can quickly get started on your own instance of Sling.
-<a name="ApacheSling-Contents"></a>
## Contents
-* [Documentation](documentation.html)
- \- Here you will find the documentation on Sling
-* [Development](development.html)
- -- Documentation on how to develop web applications with Sling and what
-tools you have at your disposal
-* [Links](links.html)
-* [Wiki](http://cwiki.apache.org/SLING/)
-* [FAQ](http://cwiki.apache.org/SLING/faq.html)
-* [Project Information](project-information.html)
+* [Documentation]({{ refs.documentation.path }}) \- Here you will find the documentation on Sling
+* [Development]({{ refs.development.path }}) -- Documentation on how to develop web applications with Sling and what tools you have at your disposal
+* [Links]({{ refs.links.path }})
+* [Wiki]({{ refs.http://cwiki.apache.org/SLING/.path }})
+* [FAQ]({{ refs.http://cwiki.apache.org/SLING/faq.html.path }})
+* [Project Information]({{ refs.project-information.path }})
-<a name="ApacheSling-UseCasesforSling"></a>
## Use Cases for Sling
-<a name="ApacheSling-Wiki"></a>
#### Wiki
-Day built a Wiki system on Sling. Each Wiki page is a node (with optional
-child nodes) in the repository. As a page is requested, the respective node
-is accessed and through the applying Component is rendered.
+Day built a Wiki system on Sling. Each Wiki page is a node (with optional child nodes) in the repository. As a page is requested, the respective node is accessed and through the applying Component is rendered.
-Thanks to the JCR Mapping and the resolution of the Component from the
-mapped Content, the system does not care for what actual node is addressed
-as long as there is a Content mapping and a Component capable of handling
-the Content.
+Thanks to the JCR Mapping and the resolution of the Component from the mapped Content, the system does not care for what actual node is addressed as long as there is a Content mapping and a Component capable of handling the Content.
-Thus in the tradition of REST, the attachement of a Wiki page, which
-happens to be in a node nested below the wiki page node is easily accessed
-using the URL of the wiki page attaching the relative path of the
-attachement ode. The system resolves the URL to the attachement Content
-and just calls the attachement's Component to spool the attachement.
+Thus in the tradition of REST, the attachement of a Wiki page, which happens to be in a node nested below the wiki page node is easily accessed using the URL of the wiki page attaching the relative path of the attachement ode. The system resolves the URL to the attachement Content and just calls the attachement's Component to spool the attachement.
-<a name="ApacheSling-DigitalAssetManagement"></a>
#### Digital Asset Management
-Day has implemented a Digital Asset Management (DAM) Application based on
-Sling. Thanks to the flexibility of the Content/Component combo as well as
-the service registration/access functionality offered by OSGi, extending
-DAM for new content type is merely a matter of implementing one or two
-interfaces and registering the respective service(s).
+Day has implemented a Digital Asset Management (DAM) Application based on Sling. Thanks to the flexibility of the Content/Component combo as well as the service registration/access functionality offered by OSGi, extending DAM for new content type is merely a matter of implementing one or two interfaces and registering the respective service(s).
Again, the managed assets may be easily spooled by directly accessing them.
-<a name="ApacheSling-WebContentManagement"></a>
#### Web Content Management
-Last but not least, Sling offers itself very well to implementing a Web
-Content Management system. Thanks to the flexibility of rendering the
-output - remember: the system does not care what to render, as long as the
-URL resolves to a Content object for which a Component exists, which is
-called to render the Content - providing support for Web Content authors
-(not PHP programmers but users out in the field) to build pages to their
-likings can easily be done.
+Last but not least, Sling offers itself very well to implementing a Web Content Management system. Thanks to the flexibility of rendering the output - remember: the system does not care what to render, as long as the URL resolves to a Content object for which a Component exists, which is called to render the Content - providing support for Web Content authors (not PHP programmers but users out in the field) to build pages to their likings can easily be done.
-<a name="ApacheSling-References"></a>
## References
-<a name="ApacheSling-ApacheJackrabbit"></a>
#### Apache Jackrabbit
-The main purpose of Sling is to develop a content-centric Web Application
-framework for Java Content Repository (JCR) based data stores. Sling is
-implemented - with the notable exception of JCR Node Type management -
-purely in terms of the JCR API and as such may use any JCR compliant
-repository. The default implementation for [Apache Jackrabbit](http://jackrabbit.apache.org)
- is provided out of the box.
+The main purpose of Sling is to develop a content-centric Web Application framework for Java Content Repository (JCR) based data stores. Sling is implemented - with the notable exception of JCR Node Type management - purely in terms of the JCR API and as such may use any JCR compliant repository. The default implementation for [Apache Jackrabbit]({{ refs.http://jackrabbit.apache.org.path }}) is provided out of the box.
-<a name="ApacheSling-OSGi"></a>
#### OSGi
-Sling is implemented as a series of [OSGi](http://www.osgi.org)
- Bundles and makes extensive use of the OSGi functionality, such as
-lifecycle management and the service layer. In addition, Sling requires
-several OSGi compendium services to be available, such as the Log Service,
-Http Service, Configuration Admin Service, Metatype Service, and
-Declarative Services.
+Sling is implemented as a series of [OSGi]({{ refs.http://www.osgi.org.path }}) Bundles and makes extensive use of the OSGi functionality, such as lifecycle management and the service layer. In addition, Sling requires several OSGi compendium services to be available, such as the Log Service, Http Service, Configuration Admin Service, Metatype Service, and Declarative Services.
-<a name="ApacheSling-ApacheFelix"></a>
#### Apache Felix
-While Sling does not require a specific OSGi framework implementation to
-run in, Sling is being developed using [Apache Felix](http://felix.apache.org)
- as the OSGi framework implementation. It has not been tested yet, but it
-is expected that Sling also operates perfectly inside other OSGi frameworks
-such as [Equinox|http://www.eclipse.org/equinox]
- and [Knopflerfish|http://www.knopflerfish.org]
-.
+While Sling does not require a specific OSGi framework implementation to run in, Sling is being developed using [Apache Felix]({{ refs.http://felix.apache.org.path }}) as the OSGi framework implementation. It has not been tested yet, but it is expected that Sling also operates perfectly inside other OSGi frameworks such as [Equinox|http://www.eclipse.org/equinox] and [Knopflerfish|http://www.knopflerfish.org].
\ No newline at end of file
Modified: sling/site/trunk/content/architecture.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/architecture.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/architecture.mdtext (original)
+++ sling/site/trunk/content/architecture.mdtext Tue May 22 08:25:18 2012
@@ -1,228 +1,97 @@
Title: Architecture
-<a name="Architecture-ArchitectureofSling"></a>
+
# Architecture of Sling
The following is a short list of high-lights of Sling:
-* *[OSGi](#osgi.html)
-* --- 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](#sling-api.html)
-* --- 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](#request-processing.html)
-* --- 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](#resources.html)
-* --- 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.html)
-* --- Servlets and Scripts are handled uniformly in that they are
-represented as resources themselves and are accessible by a resource path.
-* *[#Launchpad](#launchpad.html)
-* --- 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]({{ refs.-osgi.path }})* --- 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]({{ refs.-sling-api.path }})* --- 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]({{ refs.-request-processing.path }})* --- 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]({{ refs.-resources.path }})* --- 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]({{ refs.-servlets-and-scripts.path }})* --- Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
+* *[#Launchpad]({{ refs.-launchpad.path }})* --- 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.
-<a name="Architecture-OSGi"></a>
## OSGi
-[OSGi](http://www.osgi.org)
- 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]({{ refs.http://www.osgi.org.path }}) 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.
-<a name="Architecture-OSGiFramework"></a>
### 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:
-
-* *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.
+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.
-<a name="Architecture-CompendiumServices"></a>
### 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
-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.
+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.
-<a name="Architecture-SlingAPI"></a>
## 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.
+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](sling-api.html)
- page for more information.
+See the [Sling API]({{ refs.sling-api.path }}) page for more information.
-<a name="Architecture-RequestProcessing"></a>
## 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.
+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](servlets.html)
- page for more information.
+See the [Servlets]({{ refs.servlets.path }}) page for more information.
-<a name="Architecture-Resources"></a>
## 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*.
+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.
-See the [Resources](resources.html)
- page for more information.
+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]({{ refs.resources.path }}) page for more information.
-<a name="Architecture-ServletsandScripts"></a>
## 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<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.
+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.
-See the [Servlet Resolution](servlet-resolution.html)
- page for more information.
+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]({{ refs.servlet-resolution.path }}) page for more information.
-<a name="Architecture-Launchpad"></a>
## 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](maven-launchpad-plugin.html)
- page for information on how to do this.
+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]({{ refs.maven-launchpad-plugin.path }}) page for information on how to do this.
-See [The Sling Launchpad](the-sling-launchpad.html)
- for more information.
+See [The Sling Launchpad]({{ refs.the-sling-launchpad.path }}) for more information.
Modified: sling/site/trunk/content/assembly.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/assembly.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/assembly.mdtext (original)
+++ sling/site/trunk/content/assembly.mdtext Tue May 22 08:25:18 2012
@@ -1,178 +1,75 @@
Title: Assembly
-<a name="Assembly-Assembly:BundlingBundles"></a>
+
# 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}
-<a name="Assembly-Introduction"></a>
## 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.
-<a name="Assembly-Bundles"></a>
## 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.
+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.
+Bundles may be installed, updated , started, stopped and removed in an OSGi framework individually.
-<a name="Assembly-Assemblies"></a>
## 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.
+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.
+Assemblies are managed by the *Assembly Manager* which itself is a bundle installed into the framework.
-<a name="Assembly-Assemblymanifestheaders"></a>
### 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.
-
-* *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.
+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.
-<a name="Assembly-AssemblyLifecycle"></a>
### 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).
-<a name="Assembly-BundlesreferencedbymultipleAssemblyBundles"></a>
### 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:
-
- * 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.
+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.
-<a name="Assembly-BundleInstallation"></a>
### 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:
@@ -183,106 +80,49 @@ The following BNF defines the syntax =As
Parameter = ParameterName "=" ParameterValue .
-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.
-<a name="Assembly-BundleLocation"></a>
### 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.
-
-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.
+* *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).
+
+* *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.
-<a name="Assembly-BestPractices"></a>
## Best Practices
-<a name="Assembly-SizeofBundles"></a>
### 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:
-
- * 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.
+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.
-<a name="Assembly-NomenestOmen"></a>
### 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`.
Added: sling/site/trunk/content/authentication-actors.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/authentication-actors.mdtext?rev=1341347&view=auto
==============================================================================
--- sling/site/trunk/content/authentication-actors.mdtext (added)
+++ sling/site/trunk/content/authentication-actors.mdtext Tue May 22 08:25:18 2012
@@ -0,0 +1,62 @@
+Title: Authentication - Actors
+Excerpt: The authentication process involves a number of actors contributing to the concepts, the API and the particular implementations.
+
+# 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]({{ refs.http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/openidauth/.path }}), 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}
Added: sling/site/trunk/content/authentication-authenticationhandler.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/authentication-authenticationhandler.mdtext?rev=1341347&view=auto
==============================================================================
--- sling/site/trunk/content/authentication-authenticationhandler.mdtext (added)
+++ sling/site/trunk/content/authentication-authenticationhandler.mdtext Tue May 22 08:25:18 2012
@@ -0,0 +1,50 @@
+Title: Authentication - AuthenticationHandler
+Excerpt: The {{AuthenticationHandler}} interface defines the service API which may be implemented by authentication handlers registered as OSGi services.
+
+# 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
+
+* [Form Based AuthenticationHandler]({{ refs.form-based-authenticationhandler.path }})
+* [OpenID AuthenticationHandler]({{ refs.openid-authenticationhandler.path }})
+
+### 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///
Added: sling/site/trunk/content/authentication-framework.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/authentication-framework.mdtext?rev=1341347&view=auto
==============================================================================
--- sling/site/trunk/content/authentication-framework.mdtext (added)
+++ sling/site/trunk/content/authentication-framework.mdtext Tue May 22 08:25:18 2012
@@ -0,0 +1,112 @@
+Title: Authentication - Framework
+Excerpt: The core piece of functionality with respect to authentication in Sling is contained in the Sling Commons Auth bundle. This bundle provides the API for Sling and Sling applications to make use of authentication.
+
+# Framework
+
+The core piece of functionality with respect to authentication in Sling is contained in the Sling Commons Auth bundle. This bundle provides the API for Sling and Sling applications to make use of authentication.
+
+This support encompasses three parts:
+
+ * The `AuthenticationSupport` service provided by the `SlingAuthenticator` class. This service can be used by implementations of the OSGi `HttpContext` interface to delegate authentication.
+ * The `Authenticator` service also provided by the `SlingAuthenticator` class. This service may be used by Sling Applications to help clients login and logout.
+ * The `AuthenticationHandler` service interface. These services may be implemented by extensions to support various ways for transporting credentials from clients to the Sling server.
+
+This page describes how the `SlingAuthenticator` class provides the `AuthenticationSupport` and `Authenticator` services. For a description of the `AuthenticationHandler` service interface and the interaction between the `SlingAuthenticator` and the `AuthenticationHandler` services refer to the [AuthenticationHandler]({{ refs.authentication-authenticationhandler.path }}) page.
+
+The `SlingAuthenticator` class is an internal class of the `org.apache.sling.commons.auth` bundle and implements the `Authenticator` and `AuthenticationSupport` services.
+
+
+## AuthenticationSupport
+
+The `AuthenticationSupport` service interface defines a single method: `handleSecurity`. This method is intended to be called by the `handleSecurity` method of any `HttpContext` implementation wishing to make use of the Sling Authentication Framework.
+
+The Sling Authenticator implementation selects an `AuthenticationHandler` service appropriate for the request and calls the `AuthenticationHandler.extractCredentials` method to extract the credentials from the request. If no credentials could be extracted, the Sling Authenticator either admits the request as an anonymous request or requests authentication from the client by calling its own `login` method.
+
+
+The implementation follows this algorithm:
+
+1. Select one or more `AuthenticationHandler` for the request according to the request URL's scheme and authorization part.
+1. Call the `extractCredentials` method of each authentication handler, where the order of handler call is defined by the length of the registered path: handlers registered with longer paths are called before handlers with shorter paths. The goal is to call the handlers in order from longest request path match to shortest match. Handlers not matching the request path at all are not called.
+1. The first handler returning a non-`null` `AuthenticationInfo` result "wins" and the result is used for authentication.
+1. If any `AuthenticationInfoPostProcessor` services are registered, the `AuthenticationInfo` object is passed to their `postProcess()` method.
+1. If no handler returns a non-`null` result, the request may be handled anonymously. In these cases, an empty `AuthenticationInfo` object is passed to any `AuthenticationInfoPostProcessor` services.
+1. (Try to) log into the repository either with the provided credentials or anonymously.
+1. If there were credentials provided and the login was successful, a login event is posted *if* the `AuthenticationInfo` object contains a non-null object with the key `$$auth.info.login$$` (`AuthConstants.AUTH*INFO*LOGIN`). This event is posted with the topic `org/apache/sling/auth/core/Authenticator/LOGIN`. (added in Sling Auth Core 1.1.0)
+1. Set request attributes listed below.
+
+Extracting the credentials and trying to login to the repository may yield the following results:
+
+| Credentials | Login | Consequence |
+| present | successfull | Continue with an authenticated request |
+| present | failed | Select `AuthenticationHandler` and call `requestCredentials` method |
+| missing | anonymous allowed | Continue with a non authenticated request using anonymous access to the repository |
+| missing | anonymous forbidden | Select `AuthenticationHandler` and call `requestCredentials` method |
+
+{note}
+Only one `AuthenticationHandler` is able to provide credentials for a given request. If the credentials provided by the handler cannot be used to login to the repository, authentication fails and no further `AuthenticationHandler` is consulted.
+{note}
+
+
+#### Request Attributes on Successful Login
+
+The `handleSecurity` method gets credentials from the `AuthenticationHandler` and logs into the JCR repository using those credentials. If the login is successful, the `SlingAuthenticator` sets the following request attributes:
+
+| Attribute | Description |
+|--|--|
+| `org.osgi.service.http.authentication.remote.user` | The user ID of the JCR Session. This attribute is used by the HTTP Service implementation to implement the `HttpServletRequest.getRemoteUser` method. |
+| `org.osgi.service.http.authentication.type` | The authentication type defined by the `AuthenticationHandler`. This attribute is used by the HTTP Service implementation to implement the `HttpServletRequest.getAuthType` method. |
+| `org.apache.sling.commons.auth.ResourceResolver` | The `ResourceResolver` created from the credentials and the logged in JCR Session. This attribute may be used by servlets to access the repository. Namely the `SlingMainServlet` uses this request attribute to provide the `ResourceResolver` to handle the request. |
+| `javax.jcr.Session` | The JCR Session. This attribute is for backwards compatibility only. *Its use is deprecated and the attribute will be removed in future versions*. |
+| `org.apache.sling.commons.auth.spi.AuthenticationInfo` | The `AuthenticationInfo` object produced from the `AuthenticationHandler`. |
+
+*NOTE*: Do *NOT* use the `javax.jcr.Session` request attribute in your Sling applications. This attribute must be considered implementation specific to convey the JCR Session to the `SlingMainServlet`. In future versions of the Sling Commons Auth bundle, this request attribute will not be present anymore. To get the JCR Session for the current request adapt the request's resource resolver to a JCR Session:
+
+
+ Session session = request.getResourceResolver().adaptTo(Session.class);
+
+
+
+#### Anonymous Login
+
+The `SlingAuthenticator` provides high level of control with respect to allowing anonymous requests or requiring authentication up front:
+
+* Global setting of whether anonymous requests are allowed or not. This is the value of the *Allow Anonymous Access* (`auth.annonymous`) property of the `SlingAuthenticator` configuration. This property is supported for backwards compatibility and defaults to `true` (allowing anonymous access).
+* Specific configuration per URL. The *Authentication Requirements* (`sling.auth.requirements`) property of the `SlingAuthenticator` configuration may provide a list of URLs for which authentication may be required or not: Any entry prefixed with a dash `-` defines a subtree for which authentication is not required. Any entry not prefixed with a dash or prefixed with a plus `+` defines a subtree for which authentication is required up front and thus anonymous access is not allowed. This list is empty by default.
+* Any OSGi service may provide a `sling.auth.requirements` registration property which is used to dynamically extend the authentication requirements from the *Authentication Requirements* configuration. This may for example be set by `AuthenticationHandler` implementations providing a login form to ensure access to the login form does not require authentication. The value of this property is a single string, an array of strings or a Collection of strings and is formatted in the same way as the *Authentication Requirements* configuration property.
+
+The URLs set on the *Authentication Requirements* configuration property or the `sling.auth.requirements` service registration property can be absolute paths or URLs like the `path` service registration property of `AuthenticationHandler` services. This allows the limitation of this setup to certain requests by scheme and/or virtual host address.
+
+
+*Examples*
+
+* The `LoginServlet` contained in the Commons Auth bundle registers itself with the service registration property `sling.auth.requirements = "-/system/sling/login"` to ensure the servlet can be accessed without requiring authentication.
+
+* An authentication handler may register itself with the service registration property `sling.auth.requirements = "-/apps/sample/loginform"` to ensure the login form can be rendered without requiring authentication.
+
+
+
+## Authenticator implementation
+
+The implementation of the `Authenticator` interface is similar for both methods:
+
+*`login`*
+
+1. Select one or more `AuthenticationHandler` for the request according to the request URL's scheme and authorization part.
+1. Call the `requestCredentials` method of each authentication handler, where the order of handler call is defined by the length of the registered path: handlers registered with longer paths are called before handlers with shorter paths. The goal is to call the handlers in order from longest request path match to shortest match. Handlers not matching the request path at all are not called.
+1. As soon as the first handlers returns `true`, the process ends and it is assumed credentials have been requested from the client.
+
+The `login` method has three possible exit states:
+
+| Exit State | Description |
+|--|--|
+| Normal | An `AuthenticationHandler` could be selected to which the login request could be forwarded. |
+| `NoAuthenticationHandlerException` | No `AuthenticationHandler` could be selected to forward the login request to. In this case, the caller can proceed as appropriate. For example a servlet, which should just login a user may send back a 403/FORBIDDEN status because login is not possible. Or a 404/NOT FOUND handler, which tried to login as a fallback, may continue and send back the regular 404/NOT FOUND response. |
+| `IllegalStateException` | The response has already been committed and the login request cannot be processed. Normally to request login, the current response must be reset and a new response has to be prepared. This is only possible if the request has not yet been committed. |
+
+
+*`logout`*
+1. Select one or more `AuthenticationHandler` for the request according to the request URL's scheme and authorization part.
+1. Call the `dropCredentials` method of each authentication handler, where the order of handler call is defined by the length of the registered path: handlers registered with longer paths are called before handlers with shorter paths. The goal is to call the handlers in order from longest request path match to shortest match. Handlers not matching the request path at all are not called.
+
+Unlike for the `login` method in the `logout` method case all `AuthenticationHandler` services selected in the first step are called. If none can be selected or none can actually handle the `dropCredentials` request, the `logout` silently returns.
+
Added: sling/site/trunk/content/authentication-tasks.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/authentication-tasks.mdtext?rev=1341347&view=auto
==============================================================================
--- sling/site/trunk/content/authentication-tasks.mdtext (added)
+++ sling/site/trunk/content/authentication-tasks.mdtext Tue May 22 08:25:18 2012
@@ -0,0 +1,23 @@
+Title: Authentication - Tasks
+Excerpt: Authentication of HTTP Requests is generally a two-step process: First the credentials must be extracted from the request and second the credentials must be validated. In the case of Sling this means acquiring a JCR Session.
+
+# Tasks
+
+Authentication of HTTP Requests is generally a two-step process: First the credentials must be extracted from the request and second the credentials must be validated. In the case of Sling this means acquiring a JCR Session.
+
+## Extract Credentials from the Request
+
+ * Implemented and controlled by the Sling Commons Auth bundle
+ * Takes `HttpServletRequest`
+ * Provides credentials for futher processing (basically JCR `Credentials` and Workspace name)
+ * Extensible with the help of `AuthenticationHandler` services
+
+
+## Login to the JCR Repository
+
+ * Implemented and controlled by the JCR Repository
+ * Takes JCR `Credentials` and Workspace name
+ * Provides a JCR `Session`
+ * Implementation dependent process. Jackrabbit provides extensibility based on `LoginModules`; Sling's Embedded Jackrabbit Repository bundle provides extensibility with `LoginModulePlugin` services.
+
+Currently the credentials are always verified by trying to login to the JCR repository. Once an [ResourceResolverFactory]({{ refs.http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html.path }}) API has been added, the process of validating the credentials and logging in is actualy replaced by a process of requesting a `ResourceResolver` from the `ResourceResolverFactory`. Of course, the JCR Repository will still be the main underlying repository and as such be used to validate the credentials and get a JCR Session.
\ No newline at end of file