You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bu...@apache.org on 2012/04/22 19:20:13 UTC
svn commit: r813971 [9/11] - /websites/staging/sling/trunk/content/
Modified: websites/staging/sling/trunk/content/repository-based-development.html
==============================================================================
--- websites/staging/sling/trunk/content/repository-based-development.html (original)
+++ websites/staging/sling/trunk/content/repository-based-development.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,143 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Repository Based Development</h1> -->
+<!-- -->
+<p><a name="RepositoryBasedDevelopment-RepositoryBasedDevelopment"></a></p>
+<h1 id="repository-based-development">Repository Based Development</h1>
+<p>{toc:minLevel=2|maxLevel=3}</p>
+<p><a name="RepositoryBasedDevelopment-WebDAVSupport"></a></p>
+<h2 id="webdav-support">WebDAV Support</h2>
+<p>WebDAV support in Sling is based on the <a href="http://jackrabbit.apache.org/doc/components/jcr-server.html">Simple WebDAV</a>
+ implementation of Apache Jackrabbit which is integrated in the
+<em>jcr/webdav</em> project. This bundle provides WebDAV access to Sling's
+repository in two flavours: (1) Access to all workspaces of the repository
+on a separate URL space -- by default rooted at <em>/dav</em> in the Sling
+context -- and (2) access to the workspace used by Sling itself at the root
+of the Sling context.</p>
+<p><a name="RepositoryBasedDevelopment-Example"></a></p>
+<h4 id="example">Example</h4>
+<p>Consider Sling be installed on a Servlet container in the <em>/sling</em>
+context on <em>some.host.net:8080</em>. Here you would access the Sling
+workspace by directing your WebDAV client to the URL
+<em>http://some.host.net:8080/sling</em>. To access the <em>sample</em> workspace,
+which is not used by Sling itself, you would direct your WebDAV client to
+the URL <em>http://some.host.net:8080/sling/dav/sample</em>.</p>
+<p>Please note that accessing the repository in the separate URI space is
+actually faster, since requests do not pass the Sling resource and script
+resolution framework but instead hit the Jackrabbit Simple WebDAV Servlet
+directly.</p>
+<p><a name="RepositoryBasedDevelopment-SeparateURISpaceWebDAV"></a></p>
+<h4 id="separate-uri-space-webdav">Separate URI Space WebDAV</h4>
+<p>When accessing the repository through WebDAV in its separate URI Space, the
+URLs have the following generic structure:</p>
+<p>{panel}
+slingroot/prefix/workspace/item
+{panel}</p>
+<ul>
+<li><strong>slingroot</strong> is the URL of the Sling web application context. In
+the above example, this would <em>http://some.host.net:8080/sling</em>.</li>
+<li><strong>prefix</strong> is the URL prefix to address the WebDAV servlet. By
+default this is set to <em>/dav</em> but may be configured to any valid path.</li>
+<li><strong>workspace</strong> is the name of the workspace to be accessed through
+WebDAV.</li>
+<li><strong>item</strong> is the path to the JCR Item to access.</li>
+</ul>
+<p>If you access the WebDAV server at the prefix path -- e.g.
+<em>!http://localhost:8080/dav</em> -- you will be redirected to the default
+workspace with a temporary redirect status 302. Some clients, such as the
+Linux <em>davfs</em>, do not like this redirection and must be configured to
+explicitly address the default workspace.</p>
+<p><a name="RepositoryBasedDevelopment-Configuration"></a></p>
+<h3 id="configuration">Configuration</h3>
+<p>The Jackrabbit Simple WebDAV support in Sling has the following
+configuration options:</p>
+<table>
+<tr><th> Property </th><th> Default </th><th> Description </th></tr>
+<tr><td> Root Path </td><td> */dav* </td><td> The root path at which the Simple WebDAV Servlet
+is accessible. Access to the repository is provided in two ways. You may
+connect your WebDAV client directly to the root of the Sling web
+application to access the workspace of Sling directly. The other way is
+required if you want to connect your WebDAV client to any other workspace
+besides the Sling workspace. In this case you connect your WebDAV client to
+another a path comprised of this root path plus the name of the workspace.
+For example to connect to the *some_other* workspace, you might connect
+to *http://slinghost/dav/some_other*. </td></tr>
+<tr><td> Authentication Realm </td><td> *Sling WebDAV* </td><td> The name of the HTTP Basic
+Authentication Realm presented to the client to ask for authentication
+credentials to access the repository. </td></tr>
+<tr><td> Non Collection Node Typee </td><td> [ *nt:file*, *nt:resource* ](-*nt:file*,-*nt:resource*-.html)
+ </td><td> The JCR Node Types considered being non-collection resouces by WebDAV.
+Any node replying *true* to *Node.isNodeType()* for one of the listed
+types is considered a non-collection resource. Otherwise the respective
+node is considered a colleciton resource. </td></tr>
+<tr><td> Filter Prefixes </td><td> [ *jcr*, *rep* ](-*jcr*,-*rep*-.html)
+ </td><td> A list of namespace prefixes indicating JCR items filtered from being
+reported as collection members or properties. The default list includes jcr
+and rep (Jackrabbit internal namespace prefix) items. Do not modify this
+setting unless you know exactly what you are doing. </td></tr>
+<tr><td> Filter Node Types </td><td> -- </td><td> Nodetype names to be used to filter child nodes.
+A child node can be filtered if the declaring nodetype of its definition is
+one of the nodetype names specified in the nodetypes Element. E.g. defining
+rep:root as filtered nodetype whould result in jcr:system being hidden but
+no other child node of the root node, since those are defined by the
+nodetype nt:unstructered. The default is empty. Do not modify this setting
+unless you know exactly what you are doing. </td></tr>
+<tr><td> Filter URIs </td><td> -- </td><td> A list of namespace URIs indicating JCR items filtered
+from being reported as collection members or properties. The default list
+is empty. Do not modify this setting unless you know exactly what you are
+doing. </td></tr>
+<tr><td> Collection Primary Type </td><td> *sling:Folder* </td><td> The JCR Primary Node Type to
+assign to nodes created to reflect WebDAV collections. You may name any
+primary node type here, provided it allows the creation of nodex of this
+type and the defined Non-Collection Primary Type below it. </td></tr>
+<tr><td> Non-Collection Primary Type </td><td> *nt:file* </td><td> The JCR Primary Node Type to
+assign to nodes created to reflect WebDAV non-collection resources. You may
+name any primary node type here, provided the node type is allowed to be
+created below nodes of the type defined for the Collection Primary Type and
+that a child node with the name "jcr:content" may be created below the
+non-collection resource whose type is defined by the Content Primary Type.
+</td></tr>
+<tr><td> Content Primary Type </td><td> *nt:resource* </td><td> The JCR Primary Node Type to
+assign to the jcr:content child node of a WebDAV non-collection resource.
+You may name any primary node type here, provided the node type is allowed
+to be created as the jcr:content child node of the node type defined by the
+Non-Collection Primary Type. In addition the node type must allow at least
+the following properties: jcr:data (binary), jcr:lastModified (date), and
+jcr:mimeType (string). </td></tr>
+</table>
+<p><a name="RepositoryBasedDevelopment-AdvancedTechnicalDetails"></a></p>
+<h4 id="advanced-technical-details">Advanced Technical Details</h4>
+<p>Since the Jackrabbit Simple WebDAV Servlet is originally configured using
+an XML configuration file, which provides a great deal of flexibility, the
+integration into Sling had to assume some simplifications, of which some of
+the above parameters are part:</p>
+<p><em>IOManager</em></p>
+<p>This implementation uses the standard
+<em>org.apache.jackrabbit.server.io.IOManagerImpl</em> class and adds the
+<em>org.apache.jackrabbit.server.io.DirListingExportHandler</em> and
+<em>org.apache.jackrabbit.server.io.DefaultHandler</em> IO handlers as its only
+handlers. The <em>DefaultHandler</em> is configured from the three node types
+listed as configuration parameters above (collection, non-collection, and
+content primary node types).</p>
+<p><em>PropertyManager</em></p>
+<p>This implementation uses the standard
+<em>org.apache.jackrabbit.server.io.PropertyManagerImpl</em> and adds the same
+<em>DirListingExportHandler</em> and <em>DefaultHanlder</em> instances as its own
+handlers as are used by the IO Manager.</p>
+<p><em>ItemFilter</em></p>
+<p>This implementation uses the standard
+<em>org.apache.jackrabbit.webdav.simple.DefaultItemFilter</em> implementation as
+its item filter and configures the filter with the namespace prefixes and
+URIs as well as the node types configured as parameters.</p>
+<p><em>Collection Node Types</em></p>
+<p>This implementation only supports listing node types which are considered
+representing non-collection resources. All nodes which are instances of any
+of the configured node types are considered non-collection resources. All
+other nodes are considere collection resources.</p>
+<p><a name="RepositoryBasedDevelopment-EclipsepluginforJCR"></a></p>
+<h2 id="eclipse-plugin-for-jcr">Eclipse plugin for JCR</h2>
+<p>TBD</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/request-listeners.html
==============================================================================
--- websites/staging/sling/trunk/content/request-listeners.html (original)
+++ websites/staging/sling/trunk/content/request-listeners.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,44 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Request Listeners</h1> -->
+<!-- -->
+<p><a name="RequestListeners-RequestListenersupport"></a></p>
+<h1 id="request-listener-support">Request Listener support</h1>
+<p>Sling provides the possibility to "listen" to a request processed by the
+Sling Engine (<em>SlingMainServlet</em>). To get notified you implement the
+service interface <em>org.apache.sling.api.request.SlingRequestListener</em>.</p>
+<p><DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>SlingRequestListener</B></DIV><DIV class="codeContent panelContent">
+ public interface SlingRequestListener {</p>
+<div class="codehilite"><pre> <span class="n">static</span> <span class="n">final</span> <span class="n">String</span> <span class="n">SERVICE_NAME</span> <span class="o">=</span>
+</pre></div>
+
+<p>"org.apache.sling.api.request.SlingRequestListener"; </p>
+<div class="codehilite"><pre> /**
+ * This method is called from the Sling application for every
+ * <span class="nt"><code></span>EventType<span class="nt"></code></span> appearing during the dispatching of
+ * a Sling request
+ *
+ * @param sre the object representing the event
+ *
+ * @see org.apache.sling.api.request.SlingRequestEvent.EventType
+ */
+ public void onEvent( SlingRequestEvent sre );
+}
+</pre></div>
+
+
+<p>There are no special properties to set. </p>
+<p><a name="RequestListeners-Supportedtypesofevents"></a></p>
+<h2 id="supported-types-of-events">Supported types of events</h2>
+<p>At the moment you will get two different types of <em>SlingRequestEvent</em>:
+<table>
+<tr><th> events types (<em>SlingRequestEvent.EventType</em>) </th><th> point in time </th></tr>
+<tr><td> EVENT_INIT </td><td> after entering the <em>service</em> method in
+<em>SlingMainServlet</em>. Note that this will be <em>after</em> the <em>handleSecurity</em>
+call. </td></tr>
+<tr><td> EVENT_DESTROY </td><td> at the end of the <em>service</em> method in
+<em>SlingMainServlet</em> </td></tr></p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/request-parameters.html
==============================================================================
--- websites/staging/sling/trunk/content/request-parameters.html (original)
+++ websites/staging/sling/trunk/content/request-parameters.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,127 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Request Parameters</h1> -->
+<!-- -->
+<p><a name="RequestParameters-RequestParameterHandlinginSling"></a></p>
+<h1 id="request-parameter-handling-in-sling">Request Parameter Handling in Sling</h1>
+<p>{excerpt:hidden=true}Explains how Sling provides request parameters to the
+<em>Component</em>.{excerpt}</p>
+<p><a name="RequestParameters-ServletAPI"></a></p>
+<h2 id="servlet-api">Servlet API</h2>
+<p>The Servlet API specification provides the following methods to access the
+parameters of a request</p>
+<table>
+<tr><td> *HttpServletRequest.getQueryString()* </td><td> Returns the query part of the
+request URL </td></tr>
+<tr><td> *ServletRequest.getParameter(String)* </td><td> Returns the (first) named
+parameter </td></tr>
+<tr><td> *ServletRequest.getParameterValues(String)* </td><td> Returns all parameters of
+that name </td></tr>
+<tr><td> *ServletRequest.getParameterMap()* </td><td> Returns all parameters as a map of {{String[](.html)
+}} </td></tr>
+<tr><td> *ServletRequest.getParameterNames()* </td><td> Returns an enumeration of the
+names of the parameters </td></tr>
+</table>
+<p>As a special restriction only two kinds of parameters are supported: (1)
+Query String parameters and (2) parameters contained in the request data of
+content type <em>application/x-www-form-encoded</em>. That is file uploads using
+request data of type <em>multipart/form-data</em> are not directly supported by
+the servlet specification. Finally the actual encoding of the parameters is
+all but safe because the encoding of URLs is not very well defined and
+browsers do not set the character encoding when sending post data.
+Fortunately, they use the same character encoding for sending back form
+content as was used by the server to send the form.</p>
+<p><a name="RequestParameters-SlingAPI"></a></p>
+<h2 id="sling-api">Sling API</h2>
+<p>To overcome these restrictions and to provide uniform access to request
+parameters the Sling API in addition to the Servlet API methods to access
+parameters provides an abstraction of parameters which is applicable to all
+parameters sent by clients, the <em>RequestParameter</em> interface. Through
+this interface, each parameter may be analyzed for these topics:</p>
+<table>
+<tr><td> Raw Content </td><td> Byte array and *InputStream* representation of the
+request parameter values. You will generally use the *InputStream* to
+handle uploaded files. </td></tr>
+<tr><td> String Content </td><td> Access the values as strings is some given encoding (see
+below) or by requesting the conversion using an explicit encoding. </td></tr>
+<tr><td> File Uploads </td><td> Find out whether a parameter is a file upload, get the
+size in bytes of the parameter value and client side file name as sent by
+the browser. </td></tr>
+</table>
+
+<p>To accomodate this new interface as well as to provide easy access in the
+traditional way the <em>SlingHttpServletRequest</em> interface adds following
+methods to the standard Servlet API parameter access methods:</p>
+<table>
+<tr><td> *getRequestParameter(String)* </td><td> Returns the (first) named parameter as
+a *RequestParameter* instance </td></tr>
+<tr><td> *getRequestParameters(String)* </td><td> Returns the named parameter as an
+array of *RequestParameter* instances </td></tr>
+<tr><td> *getRequestParameterMap()* </td><td> Returns *RequestParameterMap* being a
+map of *RequestParameter* arrays indexed by parameter names </td></tr>
+</table>
+
+<p>All parameters are handled the same, that is all methods give access to the
+same parameters regardless of whether the parameters were transmitted in
+the request query, as part of form encoded data or as part of a
+<em>multipart/form-data</em> request.</p>
+<p>As of Sling Engine 2.1.0 the order or request parameters in the
+<em>getRequestParameterMap()</em>, <em>getParameterMap()</em>, and
+<em>getParameterNams()</em> is preserved as follows:</p>
+<ul>
+<li>The first entries are the parameters reported by the servlet container.
+The order of these parameters amongst each other is not defined. The
+<em>SlingHttpServletRequest</em> provides them in the same order as provided by
+the servlet container.</li>
+<li>After the servlet container provided parameters are parameters extracted from the request in case <em>multipart/form-data</em> POST requests. The order of these parameters is preserved as they are submitted in the request. This conforms to HTML 4.01 spec on forms submitted with multipart/form-data encoding: <em>A "multipart/form-data" message contains a series of parts, each representing a successful control. The parts are sent to the processing agent in the same order the corresponding controls appear in the document stream. Part boundaries should not occur in any of the data; how this is done lies outside the scope of this specification</em> (<a href="http://www.w3.org/TR/html401/interact/forms.html">17.13.4 Form content types</a>
+)</li>
+</ul>
+<p>Be warned: Only rely on request parameter ordering <em>multipart/form-data</em>
+POST requests without a query part in the request URL.</p>
+<p><a name="RequestParameters-CharacterEncoding"></a></p>
+<h2 id="character-encoding">Character Encoding</h2>
+<p>Traditionally, the encoding of parameters, especially in text area input
+forms, has been a big issue. To solve this issue Sling introduces the
+following convention:</p>
+<ul>
+<li>All forms should contain a hidden field of the name <em>_charset_</em>
+containing the actual encoding used to send the form from the server to the
+client</li>
+<li>All forms should be sent with <em>UTF-8</em> character encoding</li>
+</ul>
+<p>The first rule is essential as it helps decoding the form input correctly.
+The second rule is not actually a very hard requirement but to enable
+support for all (or most) character sets used, using <em>UTF-8</em> is one of the
+best choices anyway.</p>
+<p>When Sling is now receiving a request and is asked for the parameters, the
+parameters are parsed in two phases: The first phase just parses the raw
+input data using an identity transformation of bytes to characters. This
+identity transformation happens to generate strings as the original data
+was generated with <em>ISO-8859-1</em> encoding. The second phase locates the
+<em>_charset_</em> parameter and fixes the character encodings of the
+parameters as follows:</p>
+<ul>
+<li>All names of the parameters are re-encoded</li>
+<li>The parameter values are re-encoded, unless the parameter value is an uploaded file. Actually the parameter (not the files of course) are internally as {{byte<a href=".html"></a>
+}} where the conversion to a string is done on the fly (and yes, the
+conversion using the <em>_charset_</em> character encoding is of course cached
+for performance reasons)</li>
+<li>If the parameter is an uploaded file, the file name is re-encoded on
+the fly when accessed</li>
+</ul>
+<p>{info}
+Up to and including Sling Engine 2.2.2 request parameters are always
+decoded with ISO-8859-1 encoding if the <em>_charset_</em> request parameter
+is missing. As of Sling Engine 2.2.4 the <em>_charset_</em> request parameter
+is optional. As of this version the Sling Main Servlet supports a
+configuration setting which allows to change the default character encoding
+used if the <em>_charset_</em> request parameter is missing. To enable this
+functionality set the <em>sling.default.parameter.encoding</em> parameter of the
+Sling Main Servlet (PID <em>org.apache.sling.engine.impl.SlingMainServlet</em>)
+configuration to the desired encoding, which of course must be supported by
+the actual Java Platform.
+{info}</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/request-processing.html
==============================================================================
--- websites/staging/sling/trunk/content/request-processing.html (original)
+++ websites/staging/sling/trunk/content/request-processing.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,290 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Request Processing</h1> -->
+<!-- -->
+<p><a name="RequestProcessing-HTTPRequestProcessing"></a></p>
+<h1 id="http-request-processing">HTTP Request Processing</h1>
+<p>{note:title=Page Status}
+2008-02-13: this page is <em>out of sync</em> with the current codebase, needs to
+be reviewed and updated.
+{note}</p>
+<p>One of the core problems towards understanding how Sling works is knowing
+how a Client Request is processed by Sling. This page describes the flow of
+processing requests inside Sling.</p>
+<p><a name="RequestProcessing-CoreRequestProcessing"></a></p>
+<h2 id="core-request-processing">Core Request Processing</h2>
+<p>The HTTP request enters Sling in the
+{{org.apache.sling.core.ComponentRequestHandlerImpl.service(ServletRequest
+req, ServletResponse res)}} method as the <em>ComponentRequestHandlerImpl</em>
+is registered as the Servlet handling HTTP requests. This method sets up
+the initial <em>ComponentRequest</em> and <em>ComponentResponse</em> objects and
+hands the request over to the first <em>ComponentFilterChain</em>. This first
+filter chain calls all <em>ComponentFilter</em> instances registered as request
+level filters. After processing all filters in the request level filter
+chain, the request is handed over to the second <em>ComponentFilterChain</em>
+which calls all <em>ComponentFilter</em> instances registered as component level
+filters. At the end of the second filter chain the <em>service</em> method of
+the actual <em>Component</em> to which the request resolved is called.</p>
+<p>As the component is now processing the request, it may decide to dispatch
+the request to some other content such as for example a paragraph system or
+navigation component. To do this, the component will call the
+<em>RequestDispatcher.include</em> method. If the request dispatcher dispatches
+to a <em>Content</em> object Sling will hand the dispatch request over to the
+component level filter chain, which at the end will call the <em>service</em>
+method for the <em>Content</em> object to dispatched to. This process may be
+repeated at the component's discretion only limited by processing resources
+such as available memory.</p>
+<p>As can be seen Sling itself is absed on the Component API
+<em>ComponentFilter</em> mechanism. As such Sling provides and uses the
+following filters in the Sling Core bundle:</p>
+<p>{table:class=confluenceTable}
+{tr}{th:colspan=2|class=confluenceTh} Request Level Filters {th}{tr}
+{tr}{td:class=confluenceTd} <em>ErrorHandlerFilter</em>
+{td}{td:class=confluenceTd} Handles exceptions thrown while processing the
+request as well implements the <em>ComponentResponse.sendError()</em> method
+{td}{tr}
+{tr}{td:class=confluenceTd} <em>AuthenticationFilter</em>
+{td}{td:class=confluenceTd} Implements authentication for the request and
+provides the JCR Session of the request {td}{tr}
+{tr}{td:class=confluenceTd} <em>BurstCacheFilter</em>
+{td}{td:class=confluenceTd} Checks whether the request may be handled by
+cached response data {td}{tr}
+{tr}{td:class=confluenceTd} <em>LocaleResolverFilter</em>
+{td}{td:class=confluenceTd} Provides information on the <em>Locale</em> to be
+used for request processing. This filter implements the
+<em>ComponentRequest.getLocale()</em> method {td}{tr}
+{tr}{td:class=confluenceTd} <em>ThemeResolverFilter</em>
+{td}{td:class=confluenceTd} Provides the <em>Theme</em> for the request. The
+theme is provided as a request attribute {td}{tr}
+{tr}{td:class=confluenceTd} <em>URLMapperFilter</em> {td}{td:class=confluenceTd}
+Resolves the request URL to a JCR Node which may be mapped into a
+<em>Content</em> object {td}{tr}
+{tr}{td:class=confluenceTd} <em>ZipFilter</em> {td}{td:class=confluenceTd}
+Sample filter showing how the request response might be compressed
+according to the <em>Accept-Encoding</em> request header. This filter is not
+enabled by default. {td}{tr}
+{table}</p>
+<p>Deducing from these lists of filters, the actual request processing can be
+refined into the following steps:</p>
+<ol>
+<li>Extract user authentication information and acquire the JCR session to
+access content. If the request has no user authentication data the such
+data may be requested from the user (for example by sending a HTTP 401
+status) or an anonymous repository session might be acquired.</li>
+<li>Check whether the request may be handled by data stored in the cache.
+If the request is cacheable and a cache entry exists for the request URL,
+the request data is returned to the client and request processing may
+terminate. Otherwise request processing will continue and optionally ensure
+that any response data is entered into the cache. Of course, if the request
+is not cacheable, for example because there are request parameters, or if
+any of the <em>Component</em> instances called during request processing decide
+to signal non-cacheability for whatever reason, the response data will of
+course not cached.</li>
+<li>Extract the <em>java.util.Locale</em> from the request such that further
+processing may use properly translated messages. By default, the locale of
+the underlying Servlet request is used as the request locale. Other
+possibilities would be to use special cookies or some locale encoding in
+the path.</li>
+<li>Find the theme (or skin) to use to render the response. This step will
+add a <em>org.apache.sling.theme.Theme</em> object as a request parameter, which
+may be used by <em>Component</em>s to decide on specific rendering. For example,
+the theme may encapsulate information on the CSS to use for responses
+rendered as HTML.</li>
+<li>Resolve the request URL into a <em>Content</em> object.</li>
+</ol>
+<p>The default request level filter chain setup ends with finding the
+<em>Content</em> object requested by the request URL. After having found this
+object, the request is handed over to the component level filter chain,
+which is concerned with handling filtering on a single <em>Content</em>
+instance. As such, the component level filter chain is used for each
+<em>Content</em> object which is to be serviced either on behalf of the HTTP
+request or on behalf of request dispatcher. Thus the component level filter
+chain will generally called multiple times during a single request.</p>
+<p>{table:class=confluenceTable}
+{tr}{th:colspan=2|class=confluenceTh} Component Level Filters {th}{tr}
+{tr}{td:class=confluenceTd} <em>CacheFilter</em> {td}{td:class=confluenceTd}
+Checks whether the request to the current <em>Content</em> object may be handled
+by cached response data {td}{tr}
+{tr}{td:class=confluenceTd} <em>ComponentResolverFilter</em>
+{td}{td:class=confluenceTd} Resolves the component ID returned by the
+<em>Content.getComponentId()</em> method into a <em>Component</em> instances, which
+will be called to service the request {td}{tr}
+{table}</p>
+<p>Again, deducing from the list of filters, the following steps are taking to
+service a given <em>Content</em> object:</p>
+<ol>
+<li>Check whether the <em>Content</em> object processing may be handled from
+the cache. Same as with request level cache handling, a cache entry may
+exist for a single <em>Content</em> instance depending on whether the request is
+cacheable at all and on whether a cache entry exists. If a cache entry
+exists and may be used, the response data is simply spooled into the
+response and component level processing terminates for the <em>Content</em>
+object. Otherwise processing continues and may optionally lead to a new
+cache entry for the <em>Content</em> object to be reused later.</li>
+<li>Resolve the component ID returned by the <em>Content.getComponentId()</em>
+method into a <em>Component</em> object. Of course it is an error, if the
+component ID cannot be mapped into a <em>Component</em> object.</li>
+</ol>
+<p>After resolving the <em>Component</em> object default component filter chain
+terminates and control is handed over to the <em>service</em> method of the
+<em>Component</em> object resolved in the last step. At the discretion of the
+component request dispatchers may now be acquired to render other
+<em>Content</em> objects. In this case the component level filter chain is
+simply kicked of again resulting in the <em>service</em> method of another
+<em>Component</em> being called. And so forth.</p>
+<p><a name="RequestProcessing-ResolvingContent"></a></p>
+<h2 id="resolving-content">Resolving Content</h2>
+<p>As we have seen, the last step in the request level filter chain is the
+resolution of the request URL into a <em>Content</em> object. The URL Mapper
+Filter implementing this resolution uses an instance of the
+<em>org.apache.sling.content.ContentMapper</em> interface which is acquired by
+calling the <em>org.apache.sling.content.jcr.JcrContentManagerFactory</em> with
+the repository session acquired by the authentication filter.</p>
+<p>The URL Mapper filter then tries to apply fixed mappings from request URL
+to destination paths to support shortcut URLs. For example the root path
+<em>/</em> may be mapped into the default landing page at <em>/default/home</em>. The
+list of such mappings is configurable through the Configuration Admin
+Service.</p>
+<p>Next the URL Mapper tries to apply prefix matching patterns. A list of
+patterns is iterated checking whether the prefix applies and, if so,
+replacing the prefix with another prefix and trying to resolve the result.
+This functionality enables relocation of a subtree of the repository. For
+example, all requests whose prefix is <em>/here</em> might be remapped with the
+new prefix <em>/content/there</em>. The result of this remapping is then
+resolved.</p>
+<p>Resolution (currently) takes place on the last path segment of the request
+URL containing at least one dot. Parts of that segment are cut off after
+dots until no more dots exist in the URL. For each resulting substring, the
+<em>ContentManager.load(String)</em> method is called. This processing
+terminates if a <em>Content</em> object is found or if there is nothing to cut
+off any more.</p>
+<p>This resolution is very simple and straight forwards. Future development
+may add support for the following features:</p>
+<ul>
+<li><em>Vanity URLs</em> - Map the request URL according to the <em>Host</em> request
+header.</li>
+<li><em>Dynamic Mapping</em> - Add support for a set of variables in path and/or
+prefix mapping. For example, a prefix mapping may contain the string
+<em>/content/${lang}/${user</em>} resulting in resolving a prefix according to
+the language of the current locale and the name of the authenticated used.</li>
+</ul>
+<p><a name="RequestProcessing-RegisteringComponents"></a></p>
+<h2 id="registering-components">Registering Components</h2>
+<p>The last step of the component level filter chain is resolving the
+<em>Component</em> from the component ID of the <em>Content</em> object. Sling
+implements this resolution by making use of the OSGi service registry. That
+is, each component is to be registered as a service with the name
+<em>org.apache.sling.component.Component</em>. The <em>ComponentResolverFilter</em>
+is listening for these components and registers them internally in a map
+indexed by the IDs of the component as returned by the
+<em>Component.getId()</em> method.</p>
+<p>When a component has to be resolved, the component ID returned by the
+<em>Content</em> object is simply looked up in the component map. If found, that
+component is used. Otherwise a fall back algorithm is applied which is
+described on the <a href="default-mapping-and-rendering.html">Default Content Mapping and Request Rendering</a>
+ page.</p>
+<p><a name="RequestProcessing-ReqisteringFilters"></a></p>
+<h2 id="reqistering-filters">Reqistering Filters</h2>
+<p>Just as <em>Component</em> instances used by Sling are expected to be registered
+as OSGi services, the <em>ComponentFilter</em>s to be
+used have to be registered as services under the name
+<em>org.apache.sling.component.ComponentFilter</em>. Sling picks up all
+registered component filters and adds them to the respective filter chains.</p>
+<p>Service properties set upon registration of the filter define the chain to
+which the filter belongs and the order in which the filters should be
+processed:</p>
+<table>
+<tr><th> Property </th><th> Description </th></tr>
+<tr><td> *filter.scope* </td><td> Defines the chain to which the filter is added.
+Supported values are *component* for component level filters and
+*request* for request level filters. If this property is missing or set
+to an unknown value the filter is added to the request level filter chain.
+</td></tr>
+<tr><td> *filter.order* </td><td> Defines the weight of the filter to resolve the
+processing order. This property must be an *java.lang.Integer*. If not
+set or not an *Integer* the order defaults to *Integer.MAX_VALUE*. The
+lower the order number the earlier in the filter chain will the filter be
+inserted. If two filters are registered with the same order value, the
+filter with the lower *service.id* value is called first. </td></tr>
+</table>
+<p><a name="RequestProcessing-ContentisaJavaObject"></a></p>
+<h2 id="content-is-a-java-object">Content is a Java Object</h2>
+<p>It is crucial to understand that <em>Content</em> is an interface and the
+request processor of Sling does not actually care, how the <em>Content</em>
+instance comes to live as long as the is such an object and there is a
+<em>Component</em> instance capable of servicing the <em>Content</em> object.</p>
+<p>By default Sling uses the <em>URL Mapper</em> to resolve the request URL into a
+<em>Content</em> object. When a <em>Component</em> is tasked with servicing a
+<em>Content</em> object it usually uses the <em>ComponentRequestDispatcher</em> to
+ask Sling to service another content object generally identified by a
+(relative or absolute) path to a JCR Repository Node from which the
+<em>Content</em> object is loaded.</p>
+<p>But instead of having Sling resolve a path into a <em>Content</em> object the
+component may just as well create a <em>Content</em> object and hand it over to
+the <em>ComponentRequestDispatcher</em> for service. Consider a request which is
+handled by a <em>PageComponent</em>. This component has to draw a navigation
+tree somewhere in the response. So the component could of course insist on
+having a <em>navigation</em> child node to dispatch rendering to as follows:</p>
+<div class="codehilite"><pre><span class="n">RequestDispatcher</span> <span class="n">rd</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getRequestDispatcher</span><span class="p">(</span><span class="s">"navigation"</span><span class="p">);</span>
+<span class="n">rd</span><span class="o">.</span><span class="n">include</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">response</span><span class="p">);</span>
+</pre></div>
+
+
+<p>What happens, though, if there is no <em>navigation</em> child node ? Probably,
+the request will fail with some error status. Of course the component could
+be more clever and do:</p>
+<div class="codehilite"><pre><span class="n">Content</span> <span class="n">navigation</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getContent</span><span class="p">(</span><span class="s">"navigation"</span><span class="p">);</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">navigation</span> <span class="o">!=</span> <span class="n">null</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">RequestDispatcher</span> <span class="n">rd</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getRequestDispatcher</span><span class="p">(</span><span class="n">navigation</span><span class="p">);</span>
+ <span class="n">rd</span><span class="o">.</span><span class="n">include</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">response</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+
+
+<p>Still, if the <em>navigation</em> child node does not exist, there is no
+navigation drawn; at least there will be now error. Since Sling does not
+actually care, how a <em>Content</em> object comes to live, the component could
+do the following:</p>
+<div class="codehilite"><pre><span class="n">Content</span> <span class="n">navigation</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Content</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">public</span> <span class="n">String</span> <span class="n">getPath</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">request</span><span class="o">.</span><span class="n">getContent</span><span class="p">()</span><span class="o">.</span><span class="n">getPath</span><span class="p">()</span> <span class="o">+</span> <span class="s">"/navigation"</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="n">public</span> <span class="n">String</span> <span class="n">getComponentId</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">NavigationComponent</span><span class="o">.</span><span class="n">getClass</span><span class="p">()</span><span class="o">.</span><span class="n">getName</span><span class="p">();</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+
+<span class="n">RequestDispatcher</span> <span class="n">rd</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getRequestDispatcher</span><span class="p">(</span><span class="n">navigation</span><span class="p">);</span>
+<span class="n">rd</span><span class="o">.</span><span class="n">include</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">response</span><span class="p">);</span>
+</pre></div>
+
+
+<p>Of course, the page component now has to have knowledge about the actual
+<em>Component</em> to use.</p>
+<p>Finally, as a further enhancement, the Component might even decide to first
+check for a <em>navigation</em> child node. If such a node does not exist the
+navigation <em>Content</em> object is just created:</p>
+<div class="codehilite"><pre><span class="n">Content</span> <span class="n">navigation</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getContent</span><span class="p">(</span><span class="s">"navigation"</span><span class="p">);</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">navigation</span> <span class="o">==</span> <span class="n">null</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">navigation</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Content</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">public</span> <span class="n">String</span> <span class="n">getPath</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">request</span><span class="o">.</span><span class="n">getContent</span><span class="p">()</span><span class="o">.</span><span class="n">getPath</span><span class="p">()</span> <span class="o">+</span> <span class="s">"/navigation"</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="n">public</span> <span class="n">String</span> <span class="n">getComponentId</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">NavigationComponent</span><span class="o">.</span><span class="n">getClass</span><span class="p">()</span><span class="o">.</span><span class="n">getName</span><span class="p">();</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+
+<span class="n">RequestDispatcher</span> <span class="n">rd</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getRequestDispatcher</span><span class="p">(</span><span class="n">navigation</span><span class="p">);</span>
+<span class="n">rd</span><span class="o">.</span><span class="n">include</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">response</span><span class="p">);</span>
+</pre></div>
+
+
+<p>This could for example be used to fall back to a default navigation setup
+while providing for specialized navigation configuration in an optional
+<em>navigation</em> child node.</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/resources.html
==============================================================================
--- websites/staging/sling/trunk/content/resources.html (original)
+++ websites/staging/sling/trunk/content/resources.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,185 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Resources</h1> -->
-
+<!-- -->
+<p><a name="Resources-Resources"></a></p>
+<h1 id="resources">Resources</h1>
+<p>{toc:minLevel=2}</p>
+<p><a name="Resources-WhatisaResource"></a></p>
+<h2 id="what-is-a-resource">What is a Resource</h2>
+<p>The Resource is one of the central parts of Sling. Extending from JCR's
+<em>Everything is Content</em>, Sling assumes <em>Everthing is a Resource</em>. 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. By doing this Sling fits very well in the paradigma of
+the REST architecture.</p>
+<p><a name="Resources-HowtogetaResource"></a></p>
+<h2 id="how-to-get-a-resource">How to get a Resource</h2>
+<p>To get at Resources, you need a <em>ResourceResolver</em>. This interface
+defines four kinds of methods to access resources:
+<em> Absolute Path Mapping Resource Resolution: The
+</em>resolve(HttpServletRequest, String)<em> and </em>resolve(String)<em> methods are
+called to apply some implementation specific path matching algorithm to
+find a Resource. These methods are mainly used to map external paths - such
+as path components of request URLs - to Resources. To support creating
+external paths usable in an URL a third method </em>map(String)<em> is defined,
+which allows for round-tripping.
+</em> Absolute or Relative Path Resolution (including search path): The
+<em>getResource(String path)</em> and {{getResource(Resource base, String
+path)}} methods may be used to access a resource with an absolute path
+directly. If it can't be found the path is assumed to be relative and the
+search path retrieved from <em>getSearchPath()</em> is used to retrieve the
+resource. This mechanism is similar to resolving a programm with the
+<em>PATH</em> environment variable in your favourite operating system.
+<em> Resource Enumeration: To enumerate resources and thus iterate the
+resource tree, the </em>listChildren(Resource)<em> method may be used. This
+method returns an </em>Iterator<Resource><em> listing all resources whose path
+prefix is the path of the given Resource. This method will of course also
+cross boundaries of registered </em>ResourceProvider<em> instances to enable
+iterating the complete resource tree.
+</em> Resource Querying: Querying resources is currently only supported for JCR
+Resources through the <em>findResources(String query, String language)</em> and
+<em>queryResources(String query, String language)</em> methods. For more
+information see the section on <a href="#querying_resources.html">Querying_Resources</a>
+ below.</p>
+<p><a name="Resources-AbsolutePathMapping"></a></p>
+<h3 id="absolute-path-mapping">Absolute Path Mapping</h3>
+<p>As has been said, the absolute path mapping methods
+<em>resolve(HttpServletRequest, String)</em> and <em>resolve(String)</em> apply some
+implementation specific path matching algorithm to find a Resource. The
+difference between the two methods is that the former may take more
+properties of the <em>HttpServletRequest</em> into account when resolving the
+Resoure, while the latter just has an absolute path to work on.</p>
+<p>The general algorithm of the two methods is as follows:
+1. Call <em>HttpServletRequest.getScheme(), .getServerName(), getServerPort</em> to get an absolute path out of the request URL: [scheme](scheme.html)
+/[host].[port][path] (<em>resolve(HttpServletRequest, String)</em> method
+only, which)
+1. Check whether any virtual path matches the absolute path. If such a match
+exists, the next step is entered with the match.
+1. Apply a list of mappings in order to create a mapped path. The first
+mapped path resolving to a Resource is assumed success and the Resource
+found is returned.
+1. If no mapping created a mapped path addressing an existing Resource, the
+method fails and returns:</p>
+<ul>
+<li>The <em>resolve(String)</em> and <em>resolve(HttpServletRequest,String)</em>
+methods return a <em>NonExistingResource</em></li>
+<li>The <em>getResource(String path)</em> and {{getResource(Resource base, String
+path)}} methods return null</li>
+</ul>
+<p>The virtual path mapping may be used to create shortcut URLs for otherwise
+long and complicated URLs. An example of such an URL might be the main
+administrative page of a CMS system. So, administrators may access the root
+of the web application and directed to the main administrative page.</p>
+<p>The path mapping functionality may be used to hide internal resource
+organization from the request URL space. For example to better control the
+structure of your repository, you might decide to store all accessible data
+inside a <em>/content</em> subtree. To hide this fact from the users, a mapping
+may be defined to prefix all incoming paths with <em>/content</em> to get at the
+actual Resource.</p>
+<p>The <em>map(String)</em> applies the path mapping algorithm in the reverse
+order. That is, first the path mappings are reversed and then any virtual
+mappings are checked. So, a path <em>/content/sample</em> might be mapped
+<em>/sample</em> to revers the <em>/content</em> prefixing. Or the main
+administrative page - say <em>/system/admin/main.html</em> - may be mapped to
+the virtual URL <em>/</em>.</p>
+<p><a name="Resources-RelativePathResolution"></a></p>
+<h3 id="relative-path-resolution">Relative Path Resolution</h3>
+<p>Sometimes it is required to resolve relative paths to Resources. An example
+of such a use case is Script and Servlet resolution which starts with a
+relative path consisting of the Resource type, optional selectors and the
+request extension or method name. By scanning a search path for these
+relative paths a system provided Resource may be overwritten with some user
+defined implementation.</p>
+<p>Consider for example, the system would provide a Servlet to render Resources of type <em>nt:file</em>. This Servlet would be registered under the path <em>/libs/nt/file/html</em>. For a certain web application, this default HTML rendering might not be appropriate, so a Script is created as <em>/apps/nt/file/html.jsp</em> with a customized HTML rendering. By defining the search path to be <em>[</em> <em><em>/apps{</em>}{</em>}<em>,</em> <em><em>/libs{</em></em>} <em>](</em>-<em><em>/apps{</em>}{</em>}<em>,</em>-<em><em>/libs{</em></em>}-<em>.html)
+</em> the Servlet resolver would call the
+<em>ResourceResolver.getResource(String)</em> method with the relative path
+<em>nt/file/html</em> and be provided with the first matching resource -
+<em>/apps/nt/file/html.jsp</em> in this example.</p>
+<p>Of course the search path is not used for absolute path arguments.</p>
+<p><a name="Resources-QueryingResources"></a></p>
+<h3 id="querying-resources">Querying Resources</h3>
+<p>For convenience the <em>ResourceResolver</em> provides two Resource querying
+methods <em>findResources</em> and <em>queryResources</em> both methods take as
+arguments a JCR query string and a query language name. These parameters
+match the parameter definition of the {{QueryManager.createQuery(String
+statement, String language)}} method of the JCR API.</p>
+<p>The return value of these two methods differ in the use case:
+<em> </em>findResources<em> returns an </em>Iteratory<Resource><em> of all Resources
+matching the query. This method is comparable to calling </em>getNodes()<em> on
+the </em>QueryResult<em> returned from executing the JCR query.
+</em> <em>queryResources</em> returns an <em>Iterator<Map<String, Object>></em>. Each
+entry in the iterator is a <em>Map<String, Object</em> representing a JCR result
+<em>Row</em> in the <em>RowIterator</em> returned from executing the JCR query. The
+map is indexed by the column name and the value of each entry is the value
+of the named column as a Java Object.</p>
+<p>These methods are convenience methods to more easily post queries to the
+repository and to handle results in very straight forward way using only
+standard Java functionality.</p>
+<p>Please note, that Resource querying is currently only supported for
+repository based Resources. These query methods are not reflected in the
+<em>ResourceProvider</em> interface used to inject non-repository Resources into
+the Resource tree.</p>
+<p><a name="Resources-ProvidingResources"></a></p>
+<h2 id="providing-resources">Providing Resources</h2>
+<p>The virtual Resource tree to which the the Resource accessor methods
+<em>resolve</em> and <em>getResource</em> provide access is implemented by a
+collection of registered <em>ResourceProvider</em> instances. The main Resource
+provider is of course the repository based <em>JcrResourceProvider</em> which
+supports Node and Property based resources. This Resource provider is
+always available in Sling. Further Resource providers may or may not exist.</p>
+<p>Each Resource provider is registered as an OSGi service with a required
+service registration property <em>provider.roots</em>. This is a multi-value
+String property listing the absolute paths Resource tree entries serving as
+roots to provided subtrees. For example, if a Resource provider is
+registered with the service registration property <em>provider.roots</em> set to
+<em>/some/root</em>, all paths starting with <em>/some/root</em> are first looked up in
+the given Resource Provider.</p>
+<p>When looking up a Resource in the registered Resource providers, the
+<em>ResourceResolver</em> applies a longest prefix matching algorithm to find
+the best match. For example consider three Resource provider registered as
+follows:
+<em> JCR Resource provider as </em>/<em>
+</em> Resource provider R1 as <em>/some</em>
+<em> Resource provider R2 as </em>/some/path*</p>
+<p>When accessing a Resource with path <em>/some/path/resource</em> the Resource
+provider <em>R2</em> is first asked. If that cannot provide the resource, Resource
+provider <em>R1</em> is asked and finally the JCR Resource provider is asked. The
+first Resource provider having a Resource with the requested path will be
+used.</p>
+<p><a name="Resources-JCR-basedResources"></a></p>
+<h3 id="jcr-based-resources">JCR-based Resources</h3>
+<p>JCR-based Resources are provided with the default <em>JcrResourceProvider</em>.
+This Resource provider is always available and is always asked last. That
+is Resources provided by other Resource providers may never be overruled by
+repository based Resources.</p>
+<p><a name="Resources-Bundle-basedResources"></a></p>
+<h3 id="bundle-based-resources">Bundle-based Resources</h3>
+<p>Resources may by provided by OSGi bundles. Providing bundles have a Bundle
+manifest header <em>Sling-Bundle-Resources</em> containing a list of absolute
+paths provided by the bundle. The path are separated by comma or whitespace
+(SP, TAB, VTAB, CR, LF).</p>
+<p>The <em>BundleResourceProvider</em> supporting bundle-based Resources provides
+directories as Resources of type <em>nt:folder</em> and files as Resources of
+type <em>nt:file</em>. This matches the default primary node types intended to
+be used for directories and files in JCR repositories. For details see <a href="slingxsite:bundle-resources-(extensions.bundleresource).html">Bundle Resource.</a></p>
+<p><a name="Resources-ServletResources"></a></p>
+<h3 id="servlet-resources">Servlet Resources</h3>
+<p>Servlet Resources are registered by the Servlet Resolver bundle for
+Servlets registered as OSGi services. See <a href="slingxsite:servlets.html">Servlet Resolution</a>
+ for information on how Servlet Resources are provided.</p>
+<p><a name="Resources-FileSystemResources"></a></p>
+<h3 id="file-system-resources">File System Resources</h3>
+<p>The Filesystem Resource Provider provides access to the operating system's
+filesystem through the Sling ResourceResolver. Multiple locations may be
+mapped into the resource tree by configuring the filesystem location and
+the resource tree root path for each location to be mapped. For details see <a href="slingxsite:accessing-filesystem-resources-(extensions.fsresource).html">File System Resources</a>
+.</p>
+<p><a name="Resources-Wrap/DecorateResources"></a></p>
+<h2 id="wrapdecorate-resources">Wrap/Decorate Resources</h2>
+<p>The Sling API provides an easy way to wrap or decorate a resource before
+returning. Details see <a href="wrap-or-decorate-resources.html">Wrap or Decorate Resources</a>
+.</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/scriptengineintegration.html
==============================================================================
--- websites/staging/sling/trunk/content/scriptengineintegration.html (original)
+++ websites/staging/sling/trunk/content/scriptengineintegration.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,27 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">ScriptEngineIntegration</h1> -->
-
+<!-- -->
+<p><a name="ScriptEngineIntegration-IntegratingScriptingLanguages"></a></p>
+<h1 id="integrating-scripting-languages">Integrating Scripting Languages</h1>
+<p>This page should be extended with more concrete and detailed information.
+For now, we have the following information:</p>
+<ul>
+<li>There will be a talk at ApacheCon US 08 in New Orleans about creating
+JSR-223 ScriptEngineFactory and ScriptEngine implementaitons as well as how
+to integrate such implementations with Sling.</li>
+<li>From a mail on the mailing list, this is a very condensed how-to:
+ <strong> Create the ScriptEngine[Factory](factory.html)
+ implementations
+ </strong> Create a bundle comprising the above implementations as well as
+the script language implementation.
+ <em><em> Create the
+</em>META-INF/services/javax.script.ScriptEngineFactory</em> file listing the
+fully qualified name of your ScriptEngineFactory implementaiton</li>
+</ul>
+<p><a name="ScriptEngineIntegration-NotesonScriptEngines"></a></p>
+<h1 id="notes-on-scriptengines">Notes on ScriptEngines</h1>
+<p>{children:sort=title|excerpt=true}</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/security.html
==============================================================================
--- websites/staging/sling/trunk/content/security.html (original)
+++ websites/staging/sling/trunk/content/security.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,44 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Security</h1> -->
-
+<!-- -->
+<p><a name="Security-ReportingNewSecurityProblemswithApacheSling"></a></p>
+<h1 id="reporting-new-security-problems-with-apache-sling">Reporting New Security Problems with Apache Sling</h1>
+<p>The Apache Software Foundation takes a very active stance in eliminating
+security problems and denial of service attacks against Apache Sling.</p>
+<p>We strongly encourage folks to report such problems to our private security
+mailing list first, before disclosing them in a public forum.</p>
+<p><em>Please note that the security mailing list should only be used for
+reporting undisclosed security vulnerabilities in Apache Sling and managing
+the process of fixing such vulnerabilities. We cannot accept regular bug
+reports or other queries at this address. All mail sent to this address
+that does not relate to an undisclosed security problem in the Apache Sling
+source code will be ignored.</em></p>
+<p>If you need to report a bug that isn't an undisclosed security
+vulnerability, please use the bug reporting page.</p>
+<p>Questions about:</p>
+<ul>
+<li>how to configure Sling securely</li>
+<li>if a vulnerability applies to your particular application</li>
+<li>obtaining further information on a published vulnerability</li>
+<li>availability of patches and/or new releases</li>
+</ul>
+<p>should be addressed to the users mailing list. Please see the <a href="project-information.html">Project Information</a>
+ page for details of how to subscribe.</p>
+<p>The private security mailing address is: <a href="mailto:security@sling.apache.org.html">mailto:security@sling.apache.org</a></p>
+<p>Note that all networked servers are subject to denial of service attacks,
+and we cannot promise magic workarounds to generic problems (such as a
+client streaming lots of data to your server, or re-requesting the same URL
+repeatedly). In general our philosophy is to avoid any attacks which can
+cause the server to consume resources in a non-linear relationship to the
+size of inputs.</p>
+<p>For more information on handling security issues at the Apache Software
+Foundation please refer to the <a href="http://www.apache.org/security/">ASF Security Team</a>
+ page.</p>
+<p><a name="Security-Errorsandomissions"></a></p>
+<h1 id="errors-and-omissions">Errors and omissions</h1>
+<p>Please report any errors or omissions to <a href="mailto:security@sling.apache.org.html">mailto:security@sling.apache.org</a>
+.</p>
<div class="trademarkFooter">
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.
Modified: websites/staging/sling/trunk/content/servlet-resolution.html
==============================================================================
--- websites/staging/sling/trunk/content/servlet-resolution.html (original)
+++ websites/staging/sling/trunk/content/servlet-resolution.html Sun Apr 22 17:20:11 2012
@@ -82,7 +82,277 @@
<a href="/">Home</a>
</div>
<!-- <h1 class="title">Servlet Resolution</h1> -->
+<!-- -->
+<p><a name="ServletResolution-ServletResolution"></a></p>
+<h1 id="servlet-resolution">Servlet Resolution</h1>
+<p>{warning:title=Out Of Sync}
+Please note that the description on this page is out of sync with the most
+recent developments going on as part of implementing issue <a href="https://issues.apache.org/jira/browse/SLING-387">SLING-387</a>
+. See the links to integration tests at the end of this page for the
+Current Truth.</p>
+<p>Please see the new <a href="servlets.html">Servlets</a>
+ page.
+{warning}</p>
+<p>{toc:minLevel=2}</p>
+<p><a name="ServletResolution-ServletsareResources"></a></p>
+<h2 id="servlets-are-resources">Servlets are Resources</h2>
+<p>As explained on the <a href="resources.html">Resources</a>
+ page, the Resource is the central data abstraction of Sling. In this
+contexts, Servlets are of course also povided as Resources. As such
+Servlets may be enumerated by iterating the Resource tree and Servlets may
+be retrieved through the <em>ResourceResolver</em>.</p>
+<p>To show a Servlet inside the Resource tree, the <em>sling/servlet-resolver</em>
+project provides a <em>ServletResourceProvider</em> implementing the
+<em>ResourceProvider</em> interface. For each Servlet registered as an OSGi
+service with one or more defined service reference properties a
+<em>ServletResourceProvider</em> instance is registered.</p>
+<p>The following service reference properties are defined for Servlets defined
+as OSGi services of type <em>javax.servlet.Servlet</em>:</p>
+<table>
+<tr><th> Name </th><th> Description </th></tr>
+<tr><td> *sling.servlet.paths* </td><td> A list of absolute paths under which the
+servlet is accessible as a Resource. The property value must either be a
+single String, an array of Strings or a Vector of Strings. </td></tr>
+<tr><td> *sling.servlet.resourceTypes* </td><td> The resource type(s) supported by the
+servlet. The property value must either be a single String, an array of
+Strings or a Vector of Strings. This property is ignored if the
+*sling.servlet.paths* property is set. </td></tr>
+<tr><td> *sling.servlet.selectors* </td><td> The request URL selectors supported by the
+servlet. The selectors must be configured as they would be specified in the
+URL that is as a list of dot-separated strings such as <em>print.a4</em>.
+The property value must either be a single String, an array of Strings or a
+Vector of Strings. This property is ignored if the *sling.servlet.paths*
+property is set. </td></tr>
+<tr><td> *sling.servlet.extensions* </td><td> The request URL extensions supported by
+the servlet for GET requests. The property value must either be a single
+String, an array of Strings or a Vector of Strings. This property is
+ignored if the *sling.servlet.paths* property is set. </td></tr>
+<tr><td> *sling.servlet.methods* </td><td> The request methods supported by the
+servlet. The property value must either be a single String, an array of
+Strings or a Vector of Strings. This property is ignored if the
+*sling.servlet.paths* property is set. </td></tr>
+<tr><td> *sling.servlet.prefix* </td><td> The absolute prefix to make relative paths
+absolute. This property is a String and is optional. If it is not set, the
+actual prefix used is derived from the search path of the
+*ResourceResolver* at the time of registration. </td></tr>
+</table>
+<p>For a Servlet registered as an OSGi service to be used by the Sling Servlet
+Resolver, the following restrictions apply:</p>
+<ol>
+<li>Either the <em>sling.servlet.paths</em> or the
+<em>sling.servlet.resourceTypes</em> service reference property must be set. If
+neither is set, the Servlet service is ignored.</li>
+<li>If the <em>sling.servlet.paths</em> property is set, all other
+<em>sling.servlet.</em>* properties are ignored.</li>
+<li>Otherwise a Resource provider is registered for the Servlet for each
+permutation resource types, selectors, extensions and methods.</li>
+</ol>
+<p>Each path to be used for registration -- either from the
+<em>sling.servlet.paths</em> property or constructed from the other
+<em>sling.servlet.</em><em> properties -- must be absolute. Any relative path is
+made absolute by prefixing it with a root path. This prefix may be set with
+the </em>sling.servlet.prefix<em> service registration property. If this
+property is not set, the first entry in the </em>ResourceResolver<em> search
+path for the </em>ResourceResolver.getResource(String)<em> method is used as the
+prefix. If this entry cannot be derived, a simpe slash -- </em>/* -- is used
+as the prefix.</p>
+<p><a name="ServletResolution-Example:RegistrationbyPath"></a></p>
+<h3 id="example-registration-by-path">Example: Registration by Path</h3>
+<div class="codehilite"><pre><span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">paths</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"/libs/sling/sample/html"</span><span class="p">,</span> <span class="s">"/libs/sling/sample/txt"</span> <span class="p">]</span>
+<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">resourceTypes</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"sling/unused"</span> <span class="p">]</span>
+<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">selectors</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"img"</span> <span class="p">]</span>
+<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">extensions</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"html"</span><span class="p">,</span> <span class="s">"txt"</span><span class="p">,</span> <span class="s">"json"</span> <span class="p">]</span>
+</pre></div>
+
+
+<p>A Servlet service registered with these properties is registered under the
+following paths:</p>
+<ul>
+<li><em>/libs/sling/sample/html</em></li>
+<li><em>/libs/sling/sample/txt</em></li>
+</ul>
+<p>The registration properties <em>sling.servlet.resourceTypes</em>,
+<em>sling.servlet.selectors</em> and <em>sling.servlet.extensions</em> are ignored
+because the <em>sling.servlet.paths</em> property is set.</p>
+<p><a name="ServletResolution-Example:RegistrationbyResourceTypeetc."></a></p>
+<h3 id="example-registration-by-resource-type-etc">Example: Registration by Resource Type etc.</h3>
+<div class="codehilite"><pre><span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">resourceTypes</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"sling/unused"</span> <span class="p">]</span>
+<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">selectors</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"img"</span><span class="p">,</span> <span class="s">"tab"</span> <span class="p">]</span>
+<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">extensions</span> <span class="o">=</span> <span class="p">[</span> <span class="s">"html"</span><span class="p">,</span> <span class="s">"txt"</span><span class="p">,</span> <span class="s">"json"</span> <span class="p">]</span>
+</pre></div>
+
+
+<p>A Servlet service registered with these properties is registered under the
+following paths:</p>
+<ul>
+<li><em><em>prefix</em>/sling/unused/img/html</em></li>
+<li><em><em>prefix</em>/sling/unused/img/txt</em></li>
+<li><em><em>prefix</em>/sling/unused/img/json</em></li>
+<li><em><em>prefix</em>/sling/unused/tab/html</em></li>
+<li><em><em>prefix</em>/sling/unused/tab/txt</em></li>
+<li><em><em>prefix</em>/sling/unused/tab/json</em></li>
+</ul>
+<p>As explained the script is registered for each permutation of the resource
+types, selectors and extension. See above For an explanation of how
+<em><em>prefix</em></em> is defined.</p>
+<p><a name="ServletResolution-ScriptsareServlets"></a></p>
+<h2 id="scripts-are-servlets">Scripts are Servlets</h2>
+<p>The Sling API defines a <em>SlingScript</em> interface which is used to
+represent (executable) scripts inside of Sling. This interface is
+implemented in the <em>scripting/resolver</em> bundle in the
+<em>DefaultSlingScript</em> class which also implements the
+<em>javax.servlet.Servlet</em>.</p>
+<p>To further simplify the access to scripts from the Resource tree, the
+<em>scripting/resolver</em> bundle registers an <em>AdapterFactory</em> to adapt
+Resources to Scripts and Servlets. In fact the adapter factory returns
+instances of the <em>DefaultSlingScript</em> class for both Scripts and
+Servlets.</p>
+<p>This functionality is used by the <em>ServletResolver.resolveServlet</em>
+implementation in the <em>sling/servlet-resolver</em> bundle: This
+implementation just looks up any Resource in the resource tree according
+its lookup algorithm (see below). The first matching Resource adapting to a
+<em>javax.servlet.Servlet</em> is used for processing the resource.</p>
+<p>So from the perspective of the Servlet resolver, scripts and servlets are
+handled exactly the same.</p>
+<p><a name="ServletResolution-ResolutionProcess"></a></p>
+<h2 id="resolution-process">Resolution Process</h2>
+<p>The Servlet Resolution Process four elements of a
+<em>SlingHttpServletRequest</em>:</p>
+<ol>
+<li>The <em>resource type</em> as retrieved through
+<em>request.getResource().getResourceType()</em>. Because the resource type may
+be a node type such as <em>nt:file</em>, the resource type is mangled into a path
+by replacing any colons contained to forward slashs. Also, any backslashes
+contained are replaced to forward slashes. This should give a relative
+path. Of course a resource type may also be set to an absolute path. See
+below.</li>
+<li>The <em>request selectors</em> as retrieved through
+<em>request.getRequestPathInfo().getSelectorString()</em>. The selector string
+is turned into a realtive path by replacing all separating dots by forward
+slashes. For example the selector string <em>print.a4</em> is converted into
+the relative path <em>print/a4</em>.</li>
+<li>The <em>request extension</em> as retrieved through
+<em>request.getRequestPathInfo().getExtension()</em> if the request method is
+<em>GET</em> or <em>HEAD</em> and the request extension is not empty.</li>
+<li>The <em>request method name</em> for any request method except <em>GET</em> or
+<em>HEAD</em> or if the request extension is empty.</li>
+</ol>
+<p>The <em>resource type</em> is used as a (relative) parent path to the Servlet
+while the <em>request extension</em> or <em>request method</em> is used as the Servlet
+(base) name. The Servlet is retrieved from the Resource tree by calling the
+<em>ResourceResolver.getResource(String)</em> method which handles absolute and
+relative paths correctly by searching realtive paths in the configured
+search path.</p>
+<p>The pseudo-code for Servlet resolution is as follows:</p>
+<div class="codehilite"><pre><span class="n">Servlet</span> <span class="n">resolveServlet</span><span class="p">(</span><span class="n">SlingHttpServletRequest</span> <span class="n">request</span><span class="p">)</span> <span class="p">{</span>
+
+ <span class="n">String</span> <span class="n">resourceType</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getResource</span><span class="p">()</span><span class="o">.</span><span class="n">getResourceType</span><span class="p">();</span>
+ <span class="n">resourceType</span> <span class="o">=</span> <span class="n">resourceType</span><span class="o">.</span><span class="n">replaceAll</span><span class="p">(</span><span class="s">"\\:"</span><span class="p">,</span> <span class="s">"/"</span><span class="p">);</span>
+
+ <span class="n">String</span> <span class="n">baseName</span><span class="p">;</span>
+ <span class="k">if</span> <span class="p">((</span><span class="s">"GET"</span><span class="o">.</span><span class="n">equals</span><span class="p">(</span><span class="n">request</span><span class="o">.</span><span class="n">getMethod</span><span class="p">())</span> <span class="o">||</span>
+</pre></div>
+
+
+<p>"HEAD".equals(request.getMethod())
+ && request.getRequestPathInfo().getExtension() != null) {
+ baseName = request.getRequestPathInfo().getExtension();
+ } else {
+ baseName = request.getMethod();
+ }</p>
+<div class="codehilite"><pre> <span class="k">if</span> <span class="p">(</span><span class="n">request</span><span class="o">.</span><span class="n">getRequestPath</span><span class="p">()</span><span class="o">.</span><span class="n">getSelectorString</span><span class="p">()</span> <span class="o">!=</span> <span class="n">null</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">String</span> <span class="n">selectors</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">getRequestPath</span><span class="p">()</span><span class="o">.</span><span class="n">getSelectorString</span><span class="p">();</span>
+ <span class="n">selectors</span> <span class="o">=</span> <span class="n">selectors</span><span class="o">.</span><span class="n">replace</span><span class="p">(</span><span class="s">'.'</span><span class="p">,</span> <span class="s">'/'</span><span class="p">);</span>
+ <span class="k">while</span> <span class="p">(</span><span class="n">selectors</span> <span class="o">!=</span> <span class="n">null</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">String</span> <span class="n">path</span> <span class="o">=</span> <span class="n">resourceType</span> <span class="o">+</span> <span class="s">"/"</span> <span class="o">+</span> <span class="n">selectors</span> <span class="o">+</span> <span class="s">"/"</span> <span class="o">+</span> <span class="n">baseName</span><span class="p">;</span>
+ <span class="n">Servlet</span> <span class="n">servlet</span> <span class="o">=</span> <span class="n">findServletFor</span><span class="p">(</span><span class="n">path</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">servlet</span> <span class="o">!=</span> <span class="n">null</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">servlet</span><span class="p">;</span>
+ <span class="p">}</span>
+
+ <span class="nb">int</span> <span class="n">lastSlash</span> <span class="o">=</span> <span class="n">selectors</span><span class="o">.</span><span class="n">lastIndexOf</span><span class="p">(</span><span class="s">'/'</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">lastSlash</span> <span class="o">></span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">selectors</span> <span class="o">=</span> <span class="n">selectors</span><span class="o">.</span><span class="n">substring</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="n">lastSlash</span><span class="p">);</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="n">selectors</span> <span class="o">=</span> <span class="n">null</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+
+ <span class="n">String</span> <span class="n">path</span> <span class="o">=</span> <span class="n">resourceType</span> <span class="o">+</span> <span class="s">"/"</span> <span class="o">+</span> <span class="n">baseName</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">findScriptFor</span><span class="p">(</span><span class="n">path</span><span class="p">);</span>
+<span class="p">}</span>
+
+<span class="n">Servlet</span> <span class="n">findScriptFor</span><span class="p">(</span><span class="n">path</span><span class="p">)</span> <span class="p">{</span>
+ <span class="sr">//</span> <span class="n">Find</span> <span class="n">a</span> <span class="n">Servlet</span> <span class="ow">or</span> <span class="n">Script</span> <span class="n">with</span> <span class="n">the</span> <span class="n">given</span> <span class="n">path</span> <span class="n">in</span> <span class="n">the</span> <span class="n">search</span> <span class="n">path</span>
+ <span class="sr">//</span> <span class="n">where</span> <span class="n">the</span> <span class="n">Script</span> <span class="n">is</span> <span class="n">allowed</span> <span class="n">to</span> <span class="n">have</span> <span class="n">Script</span> <span class="n">language</span> <span class="n">specific</span>
+ <span class="sr">//</span> <span class="n">extension</span><span class="p">,</span> <span class="n">such</span> <span class="n">as</span> <span class="o">.</span><span class="n">js</span><span class="p">,</span> <span class="o">.</span><span class="n">jsp</span><span class="p">,</span> <span class="n">etc</span><span class="o">.</span>
+<span class="p">}</span>
+</pre></div>
+
+
+<p><a name="ServletResolution-DefaultServlet(s)"></a></p>
+<h2 id="default-servlets">Default Servlet(s)</h2>
+<p>As explained in the Resolution Process section above, a default Servlet is
+selected if no servlet for the current resource type can be found. To make
+the provisioning of a default Servlet as versatile as provisioning per
+resource type Servlets (or scripts), the default Servlet is selected with
+just a special resource type <em>sling/servlet/default</em>.</p>
+<p>The actual Servlet or Script called as the default Servlet is resolved
+exactly the same way as for any resource type. That is, also for the
+default Servlet selection, the request selectors and extension or method
+are considered. Also, the Servlet may be a Servlet registered as an OSGi
+service and provided through a Servlet Resource provider or it may be a
+Script stored in the repository or provided by the bundle.</p>
+<p>Finally, if not even a registered default Servlet may be resolved for the
+request, because none has been registered, the <em>sling/servlet-resolve</em>
+bundle provides a fall back <em>DefaultServlet</em> with the following
+functionality:</p>
+<ul>
+<li>If the request has no extension and the Resource of the request adapts
+to an <em>InputStream</em>, the contents of the resoure is stream out as the
+response. The response content type is taken from the <em>sling.contentType</em>
+Resource meta data or derived from the Resource path. If the
+<em>sling.characterEncoding</em> Resource meta data property is set, that value
+is used as the response character encoding. Currently there is no ETag and
+modification time stamp support.</li>
+<li>Otherwise if the object has an OCM mapping, the properties of the
+mapped object are printed.</li>
+<li>Otherwise just the path of the Resource is printed.</li>
+</ul>
+<p><a name="ServletResolution-ErrorHandlerServlet(s)"></a></p>
+<h2 id="error-handler-servlets">Error Handler Servlet(s)</h2>
+<p>The <em>sling/servlet-resolver</em> project also provides an implementation of
+the Sling Core <em>ErrorHandler</em> interface, which applies the same Servlet
+resolution process as used for normal request processing. Error handler
+Servlets and Scripts are looked up with the predefined resource
+<em>sling/servlet/errorhandler</em> and an error specific name:</p>
+<ul>
+<li><em>HTTP Status Code Handling</em>: To handle HTTP status code as used by the
+<em>HttpServletResponse.sendError</em> methods, status code is used as the
+Servlet name. For example to provide a handler for status code 404
+(NOT_FOUND), you could create a script
+<em>prefix/sling/servlet/errorhandler/404.esp</em> or for a status code 500
+(INTERNAL_SERVER_ERRROR), you might want to register a Servlet at
+<em>prefix/sling/servlet/errorhandler/500</em>.</li>
+<li><em>Throwable Handling</em>: To handle uncaught <em>Throwables</em> the simple
+name of the <em>Throwable</em> class is used as the Servlet name. Similarly to
+the Java <em>try-catch</em> clauses the class hierarchy is supported. That is to
+handle an uncaught <em>FileNotFoundException</em>, the names
+<em>FileNotFoundException</em>, <em>IOException</em>, <em>Exception</em>, <em>Throwable</em>
+are checked for a Servlet and the first one found is then used. Again, the
+Serlvet may be a Servlet registered as an OSGi service or may be a plain
+script stored in the JCR repository or provided through some custom
+Resource provider.</li>
+</ul>
+<p><a name="ServletResolution-Integrationtests"></a></p>
+<h2 id="integration-tests">Integration tests</h2>
+<p>A set of simple example servlets is available in the <a href="http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/test-services">launchpad/test-services module</a>
+. </p>
+<p>Integration tests in the <a href="http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution">launchpad/testing module</a>
+ verify that these examples are correct.</p>
+<p>Contributions to these tests and examples are welcome, of course!</p>
<div class="trademarkFooter">
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.