You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2017/06/19 12:41:21 UTC
[15/53] sling-site git commit: asf-site branch created for published
content
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/authentication/authentication-framework.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-framework.md b/content/documentation/the-sling-engine/authentication/authentication-framework.md
deleted file mode 100644
index c5a3b2c..0000000
--- a/content/documentation/the-sling-engine/authentication/authentication-framework.md
+++ /dev/null
@@ -1,122 +0,0 @@
-title=Authentication - Framework
-type=page
-status=published
-~~~~~~
-Excerpt: The core piece of functionality with respect to authentication in Sling is contained in the Sling Auth Core bundle. This bundle provides the API for Sling and Sling applications to make use of authentication.
-
-The core piece of functionality with respect to authentication in Sling is contained in the Sling Auth Core 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](/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html) page.
-
-The `SlingAuthenticator` class is an internal class of the `org.apache.sling.auth.core` 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 | successful | 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 |
-
-<div class="note">
-Only one <code>AuthenticationHandler</code> 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 <code>AuthenticationHandler</code> is consulted.
-</div>
-
-
-#### 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.auth.core.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.auth.core.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 Auth Core 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 boolean 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). Setting it to `true` is a shortcut for setting `sling.auth.requirements` to `-/`.
-* 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 request path prefix 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 values 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. The requests path (`HttpServletRequest.getServletPath()` + `HttpServletRequest.getPathInfo()`) is afterwards matched against the given paths. It matches if it starts with one of the given paths.
-
-
-**Examples**
-
-* The `LoginServlet` contained in the Sling Auth Core bundle registers itself with the service registration property `sling.auth.requirements = "-/system/sling/login"` to ensure the servlet can be accessed without requiring authentication (checks for `slash` or `dot` or `end of string`). The following request urls would work then without authentication:
-* /system/sling/login
-* /system/sling/login.html
-* /system/sling/login/somesuffix
-
-While the following request will still require authentication
-
-* /system/sling/login-test
-
-* 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.
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/authentication/authentication-tasks.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-tasks.md b/content/documentation/the-sling-engine/authentication/authentication-tasks.md
deleted file mode 100644
index ebf775e..0000000
--- a/content/documentation/the-sling-engine/authentication/authentication-tasks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-title=Authentication - Tasks
-type=page
-status=published
-~~~~~~
-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.
-
-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 Auth Core 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](http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html) 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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/default-mapping-and-rendering.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/default-mapping-and-rendering.md b/content/documentation/the-sling-engine/default-mapping-and-rendering.md
deleted file mode 100644
index fd88767..0000000
--- a/content/documentation/the-sling-engine/default-mapping-and-rendering.md
+++ /dev/null
@@ -1,7 +0,0 @@
-title=Default Mapping and Rendering
-type=page
-status=published
-~~~~~~
-translation_pending: true
-
-This page contained obsolete content, moved it to http://cwiki.apache.org/confluence/display/SLING/Default+Mapping+and+Rendering+%28OBSOLETE%29 in case it is useful to someone.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/dispatching-requests.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/dispatching-requests.md b/content/documentation/the-sling-engine/dispatching-requests.md
deleted file mode 100644
index 7a9b465..0000000
--- a/content/documentation/the-sling-engine/dispatching-requests.md
+++ /dev/null
@@ -1,77 +0,0 @@
-title=Dispatching Requests
-type=page
-status=published
-~~~~~~
-
-## Main process
-
-The following steps should give you an overview how a request is processed in Sling. Details can be found under provided links.
-
-1. The client sends the request
-
-1. This step applies only if a Servlet Container is installed and Sling is embedded: Servlet Container gets request and forwards to OSGi HttpService
-
-1. OSGi HttpService looks for responsible registered Servlet or resource (see 102.4 of the OSGi compendium)
-
-1. OSGi HttpService calls `handleSecurity` of the HttpContext associated with the servlet/resource. In case of Sling this calls into SlingMainServlet.handleSecurity and then into SlingAuthenticator.authenticate
-
-1. SlingAuthenticator selects an authentication handler for the request and forwards the authenticate call. On success a `javax.jcr.Session` is created, the request attributes required by the HTTP Service spec are set (like `org.osgi.service.http.authentication.remote.user` and `org.osgi.service.http.authentication.type`and also the `javax.jcr.Session` which is used later is set in the request attributes.
-On success, continue with step 5.
-
-1. If authentication fails either an anonymous session is acquired (if anonymous is allowed per configuration) or the login method is called.
-If anonymous is allowed, continue with step 5.
-
-1. The login method selects an AuthenticationHandler and forwards the login call to the AuthenticationHandler.requestAuthentication method to cause the client to authenticate. Request processing stops here (`SlingMainServlet.handleSecurity` returns false).
-
-1. After getting a response the HttpService either terminates the request (if authentication failed and `SlingMainServlet.handleSecurity` returned false) or continues by either spooling the resource or in the case of Sling calling the `SlingMainServlet.service` method.
-
-1. The `SlingMainServlet.service` method is the entry point into the Sling proper. This method sets up the request:
-
-* Wraps the `HttpServletRequest` and the `HttpServletResponse` into the `SlingHttpServletRequest` and the `SlingHttpServletResponse`
-* Checks if Sling is ready for processing the request (checks at the moment for an existing ResourceResolverFactory service, a ServletResolver service and a MimeTypeService)
-* Create the ResourceResolver based on the Session (by default creates a `JcrResourceResolver2`)
-* Locate the [Resource](/documentation/the-sling-engine/resources.html) on the basis of the request by calling `ResourceResovler.resolve` through `RequestData.initResource` (see also [URL decomposition](/documentation/the-sling-engine/url-decomposition.html))
-* Locate the servlet or script (see [Servlets](/documentation/the-sling-engine/servlets.html)) by calling `ServletResolver.resolveServlet` through `RequestData.initServlet`
-
-1. After this setup, the request level filters are called (the ones registered as `javax.servlet.Filter` with the property `filter.scope=request`, see [Filters](/documentation/the-sling-engine/filters.html) for details).
-If any called filter doesn't call `FilterChain.doFilter` at the end of the `Filter.doFilter` method request processing stops here.
-
-1. After having called all request level filters, the component level filters (registered with the property `filter.scope=component`, see [Filters](/documentation/the-sling-engine/filters.html) for details) are called.
-
-1. After having called the component level filters, the request servlet or script is finally called to process the request.
-
-## Include/Forward
-
-If a servlet or script is including another resource for processing through the `RequestDispatcher.include` or `RequestDispatcher.forward` (or any JSP or feature of another scripting language which relies on one of this two methods) the following processing takes place:
-
-1. Code in the processing servlet or script calls `RequestDispatcher.include` or `RequestDispatcher.forward`.
-
-1. The resource is resolved though ResourceResolver.getResource (if the RequestDispatcher has not been created with a resource already)
-
-1. The servlet or script to handle the resource is resolved calling the `ServletResolver.resolverServlet` method.
-
-1. The component level filters (registered with the property `filter.scope=component`) are called again (see [Filters](/documentation/the-sling-engine/filters.html) for details).
-
-1. The servlet or script is called to process the request.
-
-Note that these steps are processed for every include or forward call.
-
-
-## Included Request Attributes
-
-When servlet or script is called as a result of `RequestDispatcher.include` the following request attributes are set:
-
-| Attribute Name <br> Attribute Type | Description |
-|-|-|
-| `org.apache.sling.api.include.servlet` <br> `javax.servlet.Servlet` | The name of the request attribute containing the `Servlet` which included the servlet currently being active. |
-| `org.apache.sling.api.include.resource` <br>`org.apache.sling.api.resource.Resource` | The name of the request attribute containing the `Resource` underlying the `Servlet` which included the servlet currently being active. |
-| `org.apache.sling.api.include.request_path_info` <br> `org.apache.sling.api.request.RequestPathInfo` | The name of the request attribute containing the `RequestPathInfo` underlying the `Servlet` which included the servlet currently being active |
-| `javax.servlet.include.request_uri` <br> `String` | The name of the request attribute containing the `HttpServletRequest.getRequestURI()` of the request which included the servlet currently being active underlying the `Servlet` which included the servlet currently being active.<br>**Note:** In Sling, the `HttpServletRequest.getRequestURI()` method will always return the same result regardless of whether it is called from the client request processing servlet or script or from an included servlet or script. This request attribute is set for compatibility with the Servlet API specification. |
-| `javax.servlet.include.context_path` <br> `String` | The name of the request attribute containing the `HttpServletRequest.getContextPath()` of the request which included the servlet currently being active underlying the `Servlet` which included the servlet currently being active.<br>**Note:** In Sling, the `HttpServletRequest.getContextPath()` method will always return the same result regardless of whether it is called from the client request processing servlet or script or from an included servlet or script. This request attribute is set for compatibility with the Servlet API specification. |
-| `javax.servlet.include.servlet_path` <br> `String` | The name of the request attribute containing the `HttpServletRequest.getServletPath()` of the request which included the servlet currently being active underlying the `Servlet` which included the servlet currently being active.<br>**Note:** In Sling, the `HttpServletRequest.getServletPath()` method will always return the same result regardless of whether it is called from the client request processing servlet or script or from an included servlet or script. This request attribute is set for compatibility with the Servlet API specification. |
-| `javax.servlet.include.path_info` <br> `String` | The name of the request attribute containing the `HttpServletRequest.getPathInfo()` of the request which included the servlet currently being active underlying the `Servlet` which included the servlet currently being active.<br>**Note:** In Sling, the `HttpServletRequest.getPathInfo()` method will always return the same result regardless of whether it is called from the client request processing servlet or script or from an included servlet or script. This request attribute is set for compatibility with the Servlet API specification.
-| `javax.servlet.include.query_string` <br> `String` | The name of the request attribute containing the `HttpServletRequest.getQueryString()` of the request which included the servlet currently being active underlying the `Servlet` which included the servlet currently being active.<br>**Note:** In Sling, the `HttpServletRequest.getQueryString()` method will always return the same result regardless of whether it is called from the client request processing servlet or script or from an included servlet or script. This request attribute is set for compatibility with the Servlet API specification. |
-
-Constants are defined in the `org.apache.sling.api.SlingConstants` class for these request attributes.
-
-**Note:** These request attributes are not set if the servlet or script is called to handle the request or as a result of `RequestDispatcher.forward`.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/errorhandling.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/errorhandling.md b/content/documentation/the-sling-engine/errorhandling.md
deleted file mode 100644
index 74e65b9..0000000
--- a/content/documentation/the-sling-engine/errorhandling.md
+++ /dev/null
@@ -1,69 +0,0 @@
-title=Errorhandling
-type=page
-status=published
-~~~~~~
-
-The Sling Engine includes support for handling uncaught `Throwable` as well as rendering custom HTTP status code pages. This is implemented by expecting a (single) `org.apache.sling.engine.servlets.ErrorHandler` service to which handling of uncaught `Throwable` and HTTP status responses are delegated.
-
-The Sling Servlet Resolver bundle implements this interface by providing an elaborate mechanism to find the correct error handling script or servlet using the same algorithms as are used to select the scripts or servlets to handle regular requests.
-
-This page provides more information on how error handler scripts are selected and what is provided out of the box.
-
-The [ErrorHandlingTest][1] in our integration tests suite provides
-working examples of various error handling scenarios.
-
-[TOC]
-
-## Resetting the Response
-
-Errorhandler scripts and servlets are script with the current response. Before setting
-the status and writing to the response such handlers should do the following:
-
-* Check whether the response has been committed or not
-* If the response has not been committed:
-* Reset the response
-* Set the status code (use `HttpServletResponse.setStatus`)
-* Set the response content type and character encoding (provided text data is sent back)
-* If the response has already been committed:
-* Do not try to reset since this would cause an `IllegalStateException`. Also the writer may not be available.
-* The best that might be done in this case is just log a message at warning or error level along with information about the failure.
-
-
-## HTTP Status Codes
-
-The Sling engine implements the `HttpServletResponse.sendError` methods by calling the `ErrorHandler.handleError(int status, String message, SlingHttpServletRequest request, SlingHttpServletResponse response)` method.
-
-The Servlet Resolver bundle implementation looks up a script to handle the status code as follows:
-
-* The status code is converted to a string and used as the request extension. Any request extensions, selectors or suffixes from the actual request are ignored.
-* The same resource type hierarchy is followed to find the script as for regular script resolution. The difference is that for error handler scripts `sling/servlet/errorhandler` is used as the implied base resource type (as opposed to `sling/servlet/default` for regular script resolution.
-
-**Examples:**
-
-* An application provider my provide a default handler for the 404/NOT FOUND status. This script might be located in `/libs/sling/servlet/errorhandler/404.jsp`.
-* An programmer might provide a handler for the 403/FORBIDDEN status in `/apps/sling/servlet/errorhandler/403.esp`.
-
-
-## Uncaught Throwables
-
-To handle uncaught Throwables the simple name (`Class.getSimpleName()`) of the `Throwable` class is used as request extension. Similarly to the Java try-catch clauses the class hierarchy is supported. That is to handle an uncaught `FileNotFoundException`, the names `FileNotFoundException`, `IOException`, `Exception`, `Throwable` 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.
-
-**Example:**
-To register a catch-all handler for any uncaught Throwables you might create a script `/apps/sling/servlet/errorhandler/Throwable.esp`.
-
-**Note:** If no script or servlet to handle an uncaught `Throwable` is registered, the default handler kicks in, which sends back a 500/INTERNAL SERVER ERROR response containing the `Throwable` and the stack trace. This response is **not** handled by the HTTP Status Code handling described above because the response status is sent using `HttpServletResponse.setStatus(int, String)`. To prevent this default response you have to implement a catch-all handler for the `Throwable` class as shown in the example.
-
-## Default Handler
-
-The Sling Servlet Resolver bundle provides a default error handler servlet which is used if the algorithms described above do not resolve to a handler script or servlet. The provided error handler servlet does the following:
-
-* Print a descriptive message, which is the `javax.servlet.error.message` request attribute by default
-* Print a stacktrace if the `javax.servlet.error.exception` is set
-* Dump the request progress tracker
-
-Starting with Sling Servlet Resolver version 2.0.10 the default error handler servlet is looked up using the string `default` as the request extension and the provided default servlet is registered as `<prefix>/sling/servlet/errorhandler/default.servlet` where <prefix> is the last entry in the resource resolver search path, `/libs` by default.
-
-Thus to overwrite the default error handler servlet provide a servlet or script for the `default` extension, for example `/apps/sling/servlet/errorhandler/default.groovy`.
-
-
-[1]: https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolver/errorhandler/ErrorHandlingTest.java
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/featureflags.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/featureflags.md b/content/documentation/the-sling-engine/featureflags.md
deleted file mode 100644
index 180368c..0000000
--- a/content/documentation/the-sling-engine/featureflags.md
+++ /dev/null
@@ -1,27 +0,0 @@
-title=Feature Flags
-type=page
-status=published
-~~~~~~
-
-Feature Flags are used to select whether a particular feature is enabled or not. This allows to
-continuosly deploy new features of an application without making them globally available yet.
-
-Features may be enabled based on various contextual data:
-
-* Time of Day
-* Segmentation Data (gender, age, etc.), if available
-* Request Parameter
-* Request Header
-* Cookie Value
-* Static Configuration
-
-Feature flags can be provided by registering `org.apache.sling.featureflags.Feature` services.
-Alternatively feature flags can be provided by factory configuration with factory PID
-`org.apache.sling.featureflags.Feature` as follows:
-
-| Property | Description |
-|--|--|
-| `name` | Short name of this feature. This name is used to refer to this feature when checking for it to be enabled or not. This property is required and defaults to a name derived from the feature's class name and object identity. It is strongly recommended to define a useful and unique for the feature|
-| `description` | Description for the feature. The intent is to descibe the behaviour of the application if this feature would be enabled. It is recommended to define this property. The default value is the value of the name property. |
-| `enabled` | Boolean flag indicating whether the feature is enabled or not by this configuration|
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/filters.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/filters.md b/content/documentation/the-sling-engine/filters.md
deleted file mode 100644
index 1d42d90..0000000
--- a/content/documentation/the-sling-engine/filters.md
+++ /dev/null
@@ -1,122 +0,0 @@
-title=Servlet Filter Support
-type=page
-status=published
-~~~~~~
-
-Sling supports filter processing by applying filter chains to the requests before actually dispatching to the servlet or script for processing. Filters to be used in such filter processing are plain OSGi services of type `javax.servlet.Filter` which of course means that the services implement this interface.
-
-<div class="note">
-See <a href="https://issues.apache.org/jira/browse/SLING-1213">SLING-1213</a>,
-<a href="https://issues.apache.org/jira/browse/SLING-1734">SLING-1734</a>, and
-<a href="http://markmail.org/message/quxhm7d5s6u66crr">Registering filters with Sling</a>
-for more details. The
-<a href="https://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/filters/NoPropertyFilter.java">NoPropertyFilter</a>
-from our integration tests shows an example Sling Filter.
-</div>
-
-For Sling to pick up a `javax.servlet.Filter` service for filter processing two service registration properties are inspected:
-
-| Property | Type | Default Value | Valid Values | Description |
-|--|--|--|--|--|
-| `sling.filter.scope` | `String`, `String[]({{ refs..path }})` or `Vector<String>` | `request` | `REQUEST`, `INCLUDE`, `FORWARD`, `ERROR`, `COMPONENT` | Indication of which chain the filter should be added to. This property is required. If it is missing from the service, the service is ignored because it is assumed another consumer will be interested in using the service. Any unknown values of this property are also ignored causing the service to be completely ignored if none of the values provided by the property are valid. See below for the description of the filter chains. |
-| `sling.filter.pattern` | `String`| `` | Any `String` value | Restrict the filter to paths that match the supplied regular expression. Requires Sling Engine 2.4.0. |
-| `service.ranking` | `Integer` | `0` | Any `Integer` value | Indication of where to place the filter in the filter chain. The higher the number the earlier in the filter chain. This value may span the whole range of integer values. Two filters with equal `service.ranking` property value (explicitly set or default value of zero) will be ordered according to their `service.id` service property as described in section 5.2.5, Service Properties, of the OSGi Core Specification R 4.2. |
-
-
-## Filter Chains
-
-Sling maintains five filter chains: request level, component level, include filters, forward filters and error filters. Except for the component level filter these filter chains correspond to the filter `<dispatcher>` configurations as defined for Servlet API 2.5 web applications (see section SRV.6.2.5 Filters and the RequestDispatcher).
-
-The following table summarizes when each of the filter chains is called and what value must be defined in the `sling.filter.scope` property to have a filter added to the respective chain:
-
-| `sling.filter.scope` | Servlet API Correspondence | Description |
-|--|--|--|
-| `REQUEST` | `REQUEST` | Filters are called once per request hitting Sling from the outside. These filters are called after the resource addressed by the request URL and the Servlet or script to process the request has been resolved before the `COMPONENT` filters (if any) and the Servlet or script are called. |
-| `INCLUDE` | `INCLUDE` | Filters are called upon calling the `RequestDispatcher.include` method after the included resource and the Servlet or script to process the include have been resolved before the Servlet or script is called. |
-| `FORWARD` | `FORWARD` | Filters are called upon calling the `RequestDispatcher.forward` method after the included resource and the Servlet or script to process the include have been resolved before the Servlet or script is called. |
-| `ERROR` | `ERROR` | Filters are called upon `HttpServletResponse.sendError` or any uncaught `Throwable` before resolving the error handler Servlet or script. |
-| `COMPONENT` | `REQUEST,INCLUDE,FORWARD` | The `COMPONENT` scoped filters are present for backwards compatibility with earlier Sling Engine releases. These filters will be called among the `INCLUDE` and `FORWARD` filters upon `RequestDispatcher.include` or `RequestDispatcher.forward` as well as before calling the request level Servlet or script after the `REQUEST` filters. |
-
-Note on `INCLUDE` and `FORWARD` with respect to JSP tags: These filters are also called if the respective including (e.g. `<jsp:include>` or `<sling:include>`) or forwarding (e.g. `<jsp:forward>` or `<sling:forward>`) ultimately calls the `RequestDispatcher`.
-
-
-## Filter Processing
-
-Filter processing is part of the Sling request processing, which may be sketched as follows:
-
-* *Request Level*:
-* Authentication
-* Resource Resolution
-* Servlet/Script Resolution
-* Request Level Filter Processing
-
-The first step of request processing is the *Request Level* processing which is concerned with resolving the resource, finding the appropriate servlet and calling into the request level filter chain. The next step is the *Component Level* processing, calling into the component level filters before finally calling the servlet or script:
-
-* *Component Level*:
-* Component Level Filter Processing
-* Call Servlet or Script
-
-When a servlet or script is including or forwarding to another resource for processing through the `RequestDispatcher` (or any JSP tag or other language feature ultimately using a `RequestDispatcher`) the following *Dispatch* processing takes place:
-
-* *Dispatch*:
-* Resolve the resource to dispatch to if not already defined when getting the `RequestDispatcher`
-* Servlet/Script resolution
-* Call include or forward filters depending on the kind of dispatch
-* Call Servlet or Script
-
-As a consequence, request level filters will be called at most once during request processing (they may not be called at all if a filter earlier in the filter chain decides to terminate the request) while the component level, include, and forward filters may be called multiple times while processing a request.
-
-## Troubleshooting
-Apart form the logs which tell you when filters are executed, two Sling plugins provide information about filters in the OSGi console.
-
-### Recent Requests plugin
-The request traces provided at `/system/console/requests` contain information about filter execution, as in this example:
-
-0 (2010-09-08 15:22:38) TIMER_START{Request Processing}
-...
-0 (2010-09-08 15:22:38) LOG Method=GET, PathInfo=/some/path.html
-3 (2010-09-08 15:22:38) LOG Applying request filters
-3 (2010-09-08 15:22:38) LOG Calling filter: org.apache.sling.bgservlets.impl.BackgroundServletStarterFilter
-3 (2010-09-08 15:22:38) LOG Calling filter: org.apache.sling.portal.container.internal.request.PortalFilter
-3 (2010-09-08 15:22:38) LOG Calling filter: org.apache.sling.rewriter.impl.RewriterFilter
-3 (2010-09-08 15:22:38) LOG Calling filter: org.apache.sling.i18n.impl.I18NFilter
-3 (2010-09-08 15:22:38) LOG Calling filter: org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter
-3 (2010-09-08 15:22:38) LOG Applying inner filters
-3 (2010-09-08 15:22:38) TIMER_START{/some/script.jsp#0}
-...
-8 (2010-09-08 15:22:38) TIMER_END{8,Request Processing} Request Processing
-
-### Config Status plugin
-The configuration status page at `/system/console/config` includes the current list of active filters in its *Servlet Filters* category, as in this example:
-
-Current Apache Sling Servlet Filter Configuration
-
-Request Filters:
--2147483648 : class org.apache.sling.bgservlets.impl.BackgroundServletStarterFilter (2547)
--3000 : class org.apache.sling.portal.container.internal.request.PortalFilter (2562)
--2500 : class org.apache.sling.rewriter.impl.RewriterFilter (3365)
--700 : class org.apache.sling.i18n.impl.I18NFilter (2334)
-0 : class org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter (2402)
-
-Error Filters:
----
-
-Include Filters:
-
-Forward Filters:
-1000 : class some.package.DebugFilter (2449)
-
-Component Filters:
--200 : class some.package.SomeComponentFilter (2583)
-
-
-The first numbers on those lines are the filter priorities, and the last number in parentheses is the OSGi service ID.
-
-
-## Support in Sling Engine 2.1.0
-
-Up to and including Sling Engine 2.1.0 support for Servlet Filters has been as follows:
-
-* Any `javax.servlet.Filter` service is accepted as a filter for Sling unless the `pattern` property used by the [Apache Felix HttpService whiteboard support](http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheWhiteboard) is set in the service registration properties.
-* The `filter.scope` property is optional and supports the case-sensitive values `request` and `component`.
-* Filter ordering is defined by the `filter.order` property whose default value is `Integer.MAX_VALUE` where smaller values have higher priority over higher values.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/mappings-for-resource-resolution.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/mappings-for-resource-resolution.md b/content/documentation/the-sling-engine/mappings-for-resource-resolution.md
deleted file mode 100644
index 34e009f..0000000
--- a/content/documentation/the-sling-engine/mappings-for-resource-resolution.md
+++ /dev/null
@@ -1,223 +0,0 @@
-title=Mappings for Resource Resolution
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-## Configuration
-
-
-### Properties
-
-The mapping of request URLs to resources is mainly configured in a configuration tree which is (by default) located below `/etc/map`. The actual location can be configured with the `resource.resolver.map.location` property of the `org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl` configuration.
-That way you can even make it [run mode specific](/documentation/bundles/sling-settings-org-apache-sling-settings.html) by having a unique path per [run mode specific OSGi configuration]({{ refs./jcr-installer-provider.path }}).
-
-
-When dealing with the new resource resolution we have a number of properties influencing the process:
-
-* `sling:match` – This property when set on a node in the `/etc/map` tree (see below) defines a partial regular expression which is used instead of the node's name to match the incoming request. This property is only needed if the regular expression includes characters which are not valid JCR name characters. The list of invalid characters for JCR names is: `/, :, [, ], *, ', ", , |` and any whitespace except blank space. In addition a name without a name space may not be `.` or `..` and a blank space is only allowed inside the name.
-* `sling:redirect` – This property when set on a node in the `/etc/map` tree (see below) causes a redirect response to be sent to the client, which causes the client to send in a new request with the modified location. The value of this property is applied to the actual request and sent back as the value of `Location` response header.
-* `sling:status` – This property defines the HTTP status code sent to the client with the `sling:redirect` response. If this property is not set, it defaults to 302 (Found). Other status codes supported are 300 (Multiple Choices), 301 (Moved Permanently), 303 (See Other), and 307 (Temporary Redirect).
-* `sling:internalRedirect` – This property when set on a node in the `/etc/map` tree (see below) causes the current path to be modified internally to continue with resource resolution. This is a multi-value property, i.e. multiple paths can be given here, which are tried one after another until one resolved to a resource.
-* `sling:alias` – The property may be set on any resource to indicate an alias name for the resource. For example the resource `/content/visitors` may have the `sling:alias` property set to `besucher` allowing the resource to be addressed in an URL as `/content/besucher`.
-
-#### Limitation of `sling:alias` for Principal with a limited access
-
-Assuming there is
-
-* An User named `testuser`
-* An ACE with deny `jcr:all` in `/` for `everyone`
-* An ACE with allow `jcr:read` in `/content` for `testuser`
-
-If the `sling:alias` property (e.g. `myalias`) is set directly in `/content`, the User `testuser` will not be able to address the resource `/content` in an URL as `/myalias`.
-Instead if the `sling:alias` property is set in any resource under `/content` (e.g. `/content/visitors`) the `sling:alias` feature will work as usual.
-
-### Node Types
-
-To ease with the definition of redirects and aliases, the following node types are defined:
-
-* `sling:ResourceAlias` – This mixin node type defines the `sling:alias` property and may be attached to any node, which does not otherwise allow setting a property named `sling:alias`
-* `sling:MappingSpec` – This mixin node type defines the `sling:match`, `sling:redirect`, `sling:status`, and `sling:internaleRedirect` properties to define a matching and redirection inside the `/etc/map` hierarchy.
-* `sling:Mapping` – Primary node type which may be used to easily construct entries in the `/etc/map` tree. The node type extends the `sling:MappingSpec` mixin node type to allow setting the required matching and redirection. In addition the `sling:Resource` mixin node type is extended to allow setting a resource type and the `nt:hierarchyNode` node type is extended to allow locating nodes of this node type below `nt:folder` nodes.
-
-Note, that these node types only help setting the properties. The implementation itself only cares for the properties and their values and not for any of these node types.
-
-## Namespace Mangling
-
-There are systems accessing Sling, which have a hard time handling URLs containing colons – `:` – in the path part correctly. Since URLs produced and supported by Sling may contain colons because JCR Item based resources may be namespaced (e.g. `jcr:content`), a special namespace mangling feature is built into the `ResourceResolver.resolve` and `ResourceResolver(map)` methods.
-
-Namespace mangling operates such, that any namespace prefix identified in resource path to be mapped as an URL in the `map` methods is modified such that the prefix is enclosed in underscores and the colon removed.
-
-*Example*: The path `/content/*a*sample/jcr:content/jcr:data.png` is modified by namespace mangling in the `map` method to get at `/content/*a*sample/*jcr*content/*jcr*data.png`.
-
-Conversely the `resolve` methods must undo such namespace mangling to get back at the resource path. This is simple done by modifying any path such that segments starting with an underscore enclosed prefix are changed by removing the underscores and adding a colon after the prefix. There is one catch, tough: Due to the way the SlingPostServlets automatically generates names, there may be cases where the actual name would be matching this mechanism. Therefore only prefixes are modified which are actually namespace prefixes.
-
-*Example*: The path `/content/*a*sample/*jcr*content/*jcr*data.png{*`} *is modified by namespace mangling in the* `{*}resolve{*`} *method to get* `*/content/*a*sample/jcr:content/jcr:data.png{*}{`}*. The prefix* `**a{*}{`}`{`} is not modified because there is no registered namespace with prefix `a`. On the other hand the prefix `{*}jcr{*`} is modified because there is of course a registered namespace with prefix `jcr`.
-
-## Root Level Mappings
-
-Root Level Mappings apply to the request at large including the scheme, host, port and uri path. To accomplish this a path is constructed from the request lik this `{scheme}/{host}.{port}/{uri_path}`. This string is then matched against mapping entries below `/etc/map` which are structured in the content analogously. The longest matching entry string is used and the replacement, that is the redirection property, is applied.
-
-### Mapping Entry Specification
-
-Each entry in the mapping table is a regular expression, which is constructed from the resource path below `/etc/map`. If any resource along the path has a `sling:match` property, the respective value is used in the corresponding segment instead of the resource name. Only resources either having a `sling:redirect` or `sling:internalRedirect` property are used as table entries. Other resources in the tree are just used to build the mapping structure.
-
-*Example*
-
-Consider the following content
-
-/etc/map
-+-- http
-+-- example.com.80
-| +-- sling:redirect = "http://www.example.com/"
-+-- www.example.com.80
-| +-- sling:internalRedirect = "/example"
-+-- any_example.com.80
-| +-- sling:match = ".+.example.com.80"
-| +-- sling:redirect = "http://www.example.com/"
-+-- localhost_any
-| +-- sling:match = "localhost.d*"
-| +-- sling:internalRedirect = "/content"
-| +-- cgi-bin
-| | +-- sling:internalRedirect = "/scripts"
-| +-- gateway
-| | +-- sling:internalRedirect = "http://gbiv.com"
-| +-- (stories)
-| +-- sling:internalRedirect = "/anecdotes/$1"
-+-- regexmap
-+-- sling:match = "$1.example.com/$2"
-+-- sling:internalRedirect = "/content/([^/]+)/(.*)"
-
-This would define the following mapping entries:
-
-| Regular Expression | Redirect | Internal | Description |
-|--|--|--|--|
-| http/example.com.80 | http://www.example.com | no | Redirect all requests to the Second Level Domain to www |
-| http/www.example.com.80 | /example | yes | Prefix the URI paths of the requests sent to this domain with the string `/example` |
-| http/.+.example.com.80 | http://www.example.com | no | Redirect all requests to sub domains to www. The actual regular expression for the host.port segment is taken from the `sling:match` property. |
-| http/localhost.d* | /content | yes | Prefix the URI paths with `/content` for requests to localhost, regardless of actual port the request was received on. This entry only applies if the URI path does not start with `/cgi-bin`, `gateway` or `stories` because there are longer match entries. The actual regular expression for the host.port segment is taken from the `sling:match` property. |
-| http/localhost.d*/cgi-bin | /scripts | yes | Replace the `/cgi-bin` prefix in the URI path with `/scripts` for requests to localhost, regardless of actual port the request was received on. |
-| http/localhost.d*/gateway | http://gbiv.com | yes | Replace the `/gateway` prefix in the URI path with `http://gbiv.com` for requests to localhost, regardless of actual port the request was received on. |
-| http/localhost.d*/(stories) | /anecdotes/stories | yes | Prepend the URI paths starting with `/stories` with `/anecdotes` for requests to localhost, regardless of actual port the request was received on. |
-
-### Regular Expression Matching
-
-As said above the mapping entries are regular expressions which are matched against path. As such these regular expressions may also contain capturing groups as shown in the example above: `http/localhost.d*/(stories)`. After matching the path against the regular expression, the replacement pattern is applied which allows references back to the capturing groups.
-
-To illustrate the matching and replacement is applied according to the following pseudo code:
-
-#!java
-String path = request.getScheme + "/" + request.getServerName()
-+ "." + request.getServerPort() + "/" + request.getPathInfo();
-String result = null;
-for (MapEntry entry: mapEntries) {
-Matcher matcher = entry.pattern.matcher(path);
-if (matcher.find()) {
-StringBuffer buf = new StringBuffer();
-matcher.appendReplacement(buf, entry.getRedirect());
-matcher.appendTail(buf);
-result = buf.toString();
-break;
-}
-}
-
-At the end of the loop, `result` contains the mapped path or `null` if no entry matches the request `path`.
-
-**NOTE:** Since the entries in the `/etc/map` are also used to reverse map any resource paths to URLs, using regular expressions with wildcards in the Root Level Mappings prevent the respective entries from being used for reverse mappings. Therefor, it is strongly recommended to not use regular expression matching, unless you have a strong need.
-
-#### Regular Expressions for Reverse Mappings
-
-By default using regular expressions with wildcards will prevent to use the mapping entry for reverse mappings (see above).
-
-There is one exception though: If there is a `sling:internalRedirect` property containing a regular expression the map entry will be *exclusively used for reverse mappings* (i.e. used only for `ResourceResolver.map(...)`) (see also [SLING-2560](https://issues.apache.org/jira/browse/SLING-2560)). The same resource may carry a `sling:match` property with wildcards and groups referring to the groups being defined in the `sling:internalRedirect` property.
-
-This example
-
-/etc/map
-+-- http
-+-- example.com.80
-| +-- sling:internalRedirect = "/content/([^/]+)/home/(.*)"
-| +-- sling:match = "$1/index/$2"
-
-leads to the following entry being used in the reverse mapping table:
-
-| Pattern | Replacement |
-| ------- | ----------- |
-| /content/([^/]+)/home/(.*) | http://example.com/$1/index/$2 |
-
-
-### Redirection Values
-
-The result of matching the request path and getting the redirection is either a path into the resource tree or another URL. If the result is an URL, it is converted into a path again and matched against the mapping entries. This may be taking place repeatedly until an absolute or relative path into the resource tree results.
-
-The following pseudo code summarizes this behaviour:
-
-#!java
-String path = ....;
-String result = path;
-do {
-result = applyMapEntries(result);
-} while (isURL(result));
-
-As soon as the result of applying the map entries is an absolute or relative path (or no more map entries match), Root Level Mapping terminates and the next step in resource resolution, resource tree access, takes place.
-
-## Resource Tree Access
-
-The result of Root Level Mapping is an absolute or relative path to a resource. If the path is relative – e.g. `myproject/docroot/sample.gif` – the resource resolver search path (`ResourceResolver.getSearchPath()` is used to build absolute paths and resolve the resource. In this case the first resource found is used. If the result of Root Level Mapping is an absolute path, the path is used as is.
-
-Accessing the resource tree after applying the Root Level Mappings has four options:
-
-* Check whether the path addresses a so called Star Resource. A Star Resource is a resource whose path ends with or contains `/*`. Such resources are used by the `SlingPostServlet` to create new content below an existing resource. If the path after Root Level Mapping is absolute, it is made absolute by prepending the first search path entry.
-* Check whether the path exists in the repository. if the path is absolute, it is tried directly. Otherwise the search path entries are prepended to the path until a resource is found or the search path is exhausted without finding a resource.
-* Drill down the resource tree starting from the root, optionally using the search path until a resource is found.
-* If no resource can be resolved, a Missing Resource is returned.
-
-### Drilling Down the Resource Tree
-
-Drilling down the resource tree starts at the root and for each segment in the path checks whether a child resource of the given name exists or not. If not, a child resource is looked up, which has a `sling:alias` property whose value matches the given name. If neither exists, the search is terminated and the resource cannot be resolved.
-
-The following pseudo code shows this algorithm assuming the path is absolute:
-
-#!java
-String path = ...; // the absolute path
-Resource current = getResource("/");
-String[] segments = path.split("/");
-for (String segment: segments) {
-Resource child = getResource(current, segment);
-if (child == null) {
-Iterator<Resource> children = listChildren(current);
-current = null;
-while (children.hasNext()) {
-child = children.next();
-if (segment.equals(getSlingAlias(child))) {
-current = child;
-break;
-}
-}
-if (current == null) {
-// fail
-break;
-}
-} else {
-current = child;
-}
-}
-
-## Rebuild The Vanity Bloom Filter
-
-[SLING-4216](https://issues.apache.org/jira/browse/SLING-4216) introduced the usage of a bloom filter in order to resolve long startup time with many vanityPath entries.
-The bloom filter is handled automatically by the Sling framework. In some cases though, as changing the maximum number of vanity bloom filter bytes, a rebuild of the vanity bloom filter is needed.
-
-In order to rebuild vanity bloom filter:
-
-* stop Apache Sling
-* locate the org.apache.sling.resourceresolver bundle in the file system (e.g. $SLING_HOME/felix/bundleXX)
-* locate the vanityBloomFilter.txt file in the file system (e.g. $SLING_HOME/felix/bundleXX/data/vanityBloomFilter.txt)
-* delete the vanityBloomFilter.txt file
-* start Apache Sling (this might take few minutes, depending on how many vanity path entries are present)
-
-## Debugging Issues
-
-Use the Felix Web Console Plugin provided at `/system/console/jcrresolver` to inspect both the mapping and the resolver map entries. Also you can check what either `ResourceResolver.map(...)` or `ResourceResolver.resolve(...)` would return for a given URL/path.
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/request-listeners.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/request-listeners.md b/content/documentation/the-sling-engine/request-listeners.md
deleted file mode 100644
index d661e70..0000000
--- a/content/documentation/the-sling-engine/request-listeners.md
+++ /dev/null
@@ -1,35 +0,0 @@
-title=Request Listeners
-type=page
-status=published
-~~~~~~
-
-Sling provides the possibility to "listen" to a request processed by the Sling Engine (`SlingMainServlet`). To get notified you implement the service interface `org.apache.sling.api.request.SlingRequestListener`.
-
-#!java
-public interface SlingRequestListener {
-
-static final String SERVICE_NAME = "org.apache.sling.api.request.SlingRequestListener";
-
-/**
-* This method is called from the Sling application for every
-* <code>EventType</code> 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 );
-}
-
-
-There are no special properties to set.
-
-## Supported types of events
-
-At the moment you will get two different types of `SlingRequestEvent`:
-
-| events types (`SlingRequestEvent.EventType`) | point in time |
-|--|--|
-| EVENT_INIT | after entering the `service` method in `SlingMainServlet`. Note that this will be **after** the `handleSecurity` call. |
-| EVENT_DESTROY | at the end of the `service` method in `SlingMainServlet` |
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/request-parameters.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/request-parameters.md b/content/documentation/the-sling-engine/request-parameters.md
deleted file mode 100644
index 2fdea31..0000000
--- a/content/documentation/the-sling-engine/request-parameters.md
+++ /dev/null
@@ -1,84 +0,0 @@
-title=Request Parameter Handling in Sling
-type=page
-status=published
-~~~~~~
-Excerpt: Explains how Sling provides request parameters to the `Component`.
-
-## Servlet API
-
-The Servlet API specification provides the following methods to access the parameters of a request
-
-| Method | Description |
-|-|-|
-| `HttpServletRequest.getQueryString()` | Returns the query part of the request URL |
-| `ServletRequest.getParameter(String)` | Returns the (first) named parameter |
-| `ServletRequest.getParameterValues(String)` | Returns all parameters of that name |
-| `ServletRequest.getParameterMap()` | Returns all parameters as a map of `String[]({{ refs..path }})` |
-| `ServletRequest.getParameterNames()` | Returns an enumeration of the names of the parameters |
-| `ServletRequest.getParts()` | Returns all parts of the multipart request (since v3.0) |
-| `ServletRequest.getPart(String)` | Returns the request part with that name in case of multipart requests (since v3.0) |
-
-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.
-
-
-## Sling API
-
-To overcome the 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 `RequestParameter` interface. Through this interface, each parameter may be analyzed for these topics:
-
-| Type | Description |
-|-|-|
-| Raw Content | Byte array and `InputStream` representation of the request parameter values. You will generally use the `InputStream` to handle uploaded files. |
-| String Content | Access the values as strings is some given encoding (see below) or by requesting the conversion using an explicit encoding. |
-| File Uploads | 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. |
-
-To accomodate this new interface as well as to provide easy access in the traditional way the `SlingHttpServletRequest` interface adds following methods to the standard Servlet API parameter access methods:
-
-| Method | Description |
-|-|-|
-| `getRequestParameter(String)` | Returns the (first) named parameter as a `RequestParameter` instance |
-| `getRequestParameters(String)` | Returns the named parameter as an array of `RequestParameter` instances |
-| `getRequestParameterMap()` | Returns `RequestParameterMap` being a map of `RequestParameter` arrays indexed by parameter names |
-
-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 `multipart/form-data` request.
-
-As of Sling Engine 2.1.0 the order or request parameters in the `getRequestParameterMap()`, `getParameterMap()`, and `getParameterNams()` is preserved as follows:
-
-* The first entries are the parameters reported by the servlet container. The order of these parameters amongst each other is not defined. The `SlingHttpServletRequest` provides them in the same order as provided by the servlet container.
-* After the servlet container provided parameters are parameters extracted from the request in case `multipart/form-data` 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: *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* ([17.13.4 Form content types](http://www.w3.org/TR/html401/interact/forms.html))
-
-Be warned: Only rely on request parameter ordering `multipart/form-data` POST requests without a query part in the request URL.
-
-### Effects of Sling on Servlet API parameter methods
-
-From within Sling servlets/scripts you can no longer rely on the original semantics of the Servlet API methods for dealing with parameters as
-
-* `ServletRequest.getParameter(String)`
-* `ServletRequest.getParameterValues(String)`
-* `ServletRequest.getParameterMap()`
-* `ServletRequest.getParameterNames()`
-* `ServletRequest.getParts()` and
-* `ServletRequest.getPart(String)`
-
-internally use the Sling parameter support (and therefore have the same implications on e.g. encoding). You should preferably use the Sling methods `getRequestParameter*` instead.
-
-Calling `ServletRequest.getInputStream()` is not supported, nor relying on some 3rd party libraries which are internally using that method like [Apache Commons Fileupload](https://commons.apache.org/proper/commons-fileupload/). This is because the Sling parameter support needs exclusive access to the request's input stream.
-
-## Character Encoding
-
-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:
-
-* All forms should contain a hidden field of the name `_charset_` containing the actual encoding used to send the form from the server to the client
-* All forms should be sent with *UTF-8* character encoding
-
-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 *UTF-8* is one of the best choices anyway.
-
-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 `ISO-8859-1` encoding. The second phase locates the `_charset_` parameter and fixes the character encodings of the parameters as follows:
-
-* All names of the parameters are re-encoded
-* 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[]({{ refs..path }})` where the conversion to a string is done on the fly (and yes, the conversion using the `_charset_` character encoding is of course cached for performance reasons)
-* If the parameter is an uploaded file, the file name is re-encoded on the fly when accessed
-
-<div class="info">
-Up to and including Sling Engine 2.2.2 request parameters are always decoded with ISO-8859-1 encoding if the <code>_charset_</code> request parameter is missing. As of Sling Engine 2.2.4 the <code>_charset_</code> 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 <code>_charset_</code> request parameter is missing.
-To enable this functionality set the <code>sling.default.parameter.encoding</code> parameter of the Sling Main Servlet (PID <code>org.apache.sling.engine.impl.SlingMainServlet</code>) configuration (for Sling Engine < 2.3.0) or the same parameter of the Sling Request Parameter Handling (PID <code>org.apache.sling.engine.parameters</code>) configuration (for Sling Engine >= 2.3.0 ) to the desired encoding, which of course must be supported by the actual Java Platform.
-</div>
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/the-sling-engine/resources.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/resources.md b/content/documentation/the-sling-engine/resources.md
deleted file mode 100644
index 387a192..0000000
--- a/content/documentation/the-sling-engine/resources.md
+++ /dev/null
@@ -1,180 +0,0 @@
-title=Resources
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-## What is a Resource
-
-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. By doing this Sling fits very well in the paradigma of the REST architecture.
-
-### Resource Properties
-
-Resources have a number of essentiall properties:
-
-| Property | Description |
-|--|--|
-| Path | Resources are part of a Resource Tree. As such each Resource has a path which is formed by concatenating the names of all Resources along the root to the Resource separated by a slash. Ok, really, this is much like a URL path or a file system path where the slash (`/`) is the separator character. |
-| Name | The name of the Resource is the last element (or segment) in the path. |
-| Resource Type | Each resource has a resource type which is used by the Servlet and Script resolver to find the appropriate Servlet or Script to handle the request for the Resource. |
-| Resource Super Type | The (optional explicit) super type of the Resource. See the section _Resource Types_ below for more details. |
-| Adapters | Resources are always `Adaptable` and therefore can be adapted to a different view. See the section _Resource Adapters_ below for more details. |
-| Metadata | Resources in general support [link text][1] providing access to values such as the length of a binary resource (which can be streamed) or the Resource's content type. |
-
-For a complete description of the `Resource` interface, please refer to the [link text][2] JavaDoc.
-
-### Resource Types
-
-The exact method of setting the resource type for a Resource depends on the actual Resource Provider. For the four main Resource Provider
-implementations provided by Sling, the assignments are as follows:
-
-| Provider | Resource Type | Resource Super Type |
-|--|--|--|
-| JCR | The value of the `sling:resourceType` property or the primary node type if the property is not set (a namespace separator colon is replaced by a slash, e.g. the `nt:file` primary node type is mapped to the `nt/file` resource type | The value of the `sling:resourceSuperType` of the Resource node or resource super type of the resource pointed to by the resource type (when accessed with `ResourceResolver.getResource(String)` |
-| File System | File based resources are of type `nt/file`; folder based resources are of type `nt/folder` corresponding to the respective JCR primary node type | none |
-| Bundle | File based resources are of type `nt/file`; folder based resources are of type `nt/folder` corresponding to the respective JCR primary node type | none |
-| Servlet | The absolute path of the resource appended with the suffix `.servlet` | `sling/bundle/resource` |
-
-Resource Types form a type hierarchy much like Java classes form a type hierarchy. Each resource type has a resource super type, either explicitly defined as for example for JCR or Servlet Resources or implicitly. The implicit Resource Super Type is at the same time the root Resource Type much like the `java.lang.Object` class is called `sling/servlet/default` (for historical reasons). The `sling/servlet/default` Resource Type is the only type without a super type.
-
-### Adapters
-
-The object types to which Resources may be adapted depend mostly depends on the Resource Provider providing the resource. For example all JCR node based resources always adapt to `javax.jcr.Node` objects.
-
-If the actual Resource object class implementation extends from the `SlingAdaptable` class, then in addition all `AdapterFactory` services adapting `Resource` objects are considered when trying to adapt the Resource. In general Resource Providers are recommended to have their Resource implementation extend from [link text][3] which guarantees the Resource implementation to extend from `SlingAdaptable` and thus supporting Adapter Factories.
-
-## How to get a Resource
-
-To get at Resources, you need a `ResourceResolver`. This interface defines four kinds of methods to access resources:
-
-* Absolute Path Mapping Resource Resolution: The `resolve(HttpServletRequest, String)` and `resolve(String)` 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 `map(String)` is defined, which allows for round-tripping.
-* Absolute or Relative Path Resolution (including search path): The `getResource(String path)` 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 `getSearchPath()` is used to retrieve the resource. This mechanism is similar to resolving a programm with the `PATH` environment variable in your favourite operating system.
-* Resource Enumeration: To enumerate resources and thus iterate the resource tree, the `listChildren(Resource)` method may be used. This method returns an `Iterator<Resource>` listing all resources whose path prefix is the path of the given Resource. This method will of course also cross boundaries of registered `ResourceProvider` instances to enable iterating the complete resource tree.
-* Resource Querying: Querying resources is currently only supported for JCR Resources through the `findResources(String query, String language)` and `queryResources(String query, String language)` methods. For more information see the section on [Querying Resources](#querying-resources) below.
-
-### Absolute Path Mapping
-
-As has been said, the absolute path mapping methods `resolve(HttpServletRequest, String)` and `resolve(String)` 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 `HttpServletRequest` into account when resolving the Resoure, while the latter just has an absolute path to work on.
-
-The general algorithm of the two methods is as follows:
-
-1. Call `HttpServletRequest.getScheme(), .getServerName(), getServerPort` to get an absolute path out of the request URL: [scheme]({{ refs.scheme.path }})/[host].[port][path] (`resolve(HttpServletRequest, String)` 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 a `NonExistingResource` (for the
-`resolve(String)` and `resolve(HttpServletRequest,String)`) or null (for the `getResource(String path)`
-and `getResource(Resource base, String path)` methods).
-
-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.
-
-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 `/content` subtree. To hide this fact from the users, a mapping may be defined to prefix all incoming paths with `/content` to get at the actual Resource.
-
-The `map(String)` 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 `/content/sample` might be mapped `/sample` to revers the `/content` prefixing. Or the main administrative page - say `/system/admin/main.html` - may be mapped to the virtual URL `/`.
-
-More details on mappings can be found at [Mappings for Resource Resolution](/documentation/the-sling-engine/mappings-for-resource-resolution.html).
-
-### Relative Path Resolution
-
-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.
-
-Consider for example, the system would provide a Servlet to render Resources of type `nt:file`. This Servlet would be registered under the path `/libs/nt/file/html`. For a certain web application, this default HTML rendering might not be appropriate, so a Script is created as `/apps/nt/file/html.jsp` with a customized HTML rendering. By defining the search path to be `[/apps,/libs]` the Servlet resolver would call the `ResourceResolver.getResource(String)` method with the relative path `nt/file/html` and be provided with the first matching resource - `/apps/nt/file/html.jsp` in this example.
-
-Of course the search path is not used for absolute path arguments.
-
-### Querying Resources
-
-For convenience the `ResourceResolver` provides two Resource querying methods `findResources` and `queryResources` 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.
-
-The return value of these two methods differ in the use case:
-
-* `findResources` returns an `Iteratory<Resource>` of all Resources matching the query. This method is comparable to calling `getNodes()` on the `QueryResult` returned from executing the JCR query.
-* `queryResources` returns an `Iterator<Map<String, Object>>`. Each entry in the iterator is a `Map<String, Object` representing a JCR result `Row` in the `RowIterator` 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.
-
-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.
-
-Please note, that Resource querying is currently only supported for repository based Resources. These query methods are not reflected in the `ResourceProvider` interface used to inject non-repository Resources into the Resource tree.
-
-## Providing Resources
-
-The virtual Resource tree to which the the Resource accessor methods `resolve` and `getResource` provide access is implemented by a collection of registered `ResourceProvider` instances. The main Resource provider is of course the repository based `JcrResourceProvider` which supports Node and Property based resources. This Resource provider is always available in Sling. Further Resource providers may or may not exist.
-
-Each Resource provider is registered as an OSGi service with a required service registration property `provider.roots`. 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 `provider.roots` set to */some/root*, all paths starting with `/some/root` are first looked up in the given Resource Provider.
-
-When looking up a Resource in the registered Resource providers, the `ResourceResolver` applies a longest prefix matching algorithm to find the best match. For example consider three Resource provider registered as follows:
-
-* JCR Resource provider as `/`
-* Resource provider R1 as `/some`
-* Resource provider R2 as `/some/path`
-
-When accessing a Resource with path `/some/path/resource` the Resource provider *R2* is first asked. If that cannot provide the resource, Resource provider *R1* is asked and finally the JCR Resource provider is asked. The first Resource provider having a Resource with the requested path will be used.
-
-### JCR-based Resources
-
-JCR-based Resources are provided with the default `JcrResourceProvider`. 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.
-
-### Bundle-based Resources
-
-Resources may by provided by OSGi bundles. Providing bundles have a Bundle manifest header `Sling-Bundle-Resources` containing a list of absolute paths provided by the bundle. The path are separated by comma or whitespace (SP, TAB, VTAB, CR, LF).
-
-The `BundleResourceProvider` supporting bundle-based Resources provides directories as Resources of type `nt:folder` and files as Resources of type `nt:file`. This matches the default primary node types intended to be used for directories and files in JCR repositories.
-
-For details see [Bundle Resource.](/documentation/bundles/bundle-resources-extensions-bundleresource.html)
-
-### Servlet Resources
-
-Servlet Resources are registered by the Servlet Resolver bundle for Servlets registered as OSGi services. See [Servlet Resolution](/documentation/the-sling-engine/servlets.html) for information on how Servlet Resources are provided.
-
-### File System Resources
-
-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 [File System Resources](/documentation/bundles/accessing-filesystem-resources-extensions-fsresource.html).
-
-### Merged Resources
-
-The merged resource provider exposes a view on merged resources from multiple locations.
-
-For details see [Resource Merger](/documentation/bundles/resource-merger.html).
-
-### Custom Resource providers
-Custom ResourceProvider services can be used to integrate your own custom resources in the Sling resource tree.
-
-For a simple example of that, see the [PlanetResourceProvider][4] used in our integration tests.
-
-## Writeable Resources
-Sling now supports full CRUD functionality on Resources, without necessarily having to go through the JCR API.
-
-The advantage is that this works for any ResourceProvider that supports the required operations.
-
-See the testSimpleCRUD method in [WriteableResourcesTest][5] for a basic example of how that works.
-More details can be found at [Sling API CRUD Support](/documentation/the-sling-engine/sling-api-crud-support.html).
-
-## Resource Observation
-
-To be notified whenever certain resources or their properties have been modified/added/removed there are different possibilities
-
-### Resource Observation API (ResourceChangeListener)
-
-*This API is only available since Sling API 2.11.0 ([SLING-4751](https://issues.apache.org/jira/browse/SLING-4751)).*
-
-Register an OSGi service for [`org.apache.sling.api.resource.observation.ResourceChangeListener`][6] or [`org.apache.sling.api.resource.observation.ExternalResourceChangeListener`][7] to be notified about changes. Certain properties can be used to restrict subscription to only a subset of events.
-
-### OSGi Event Admin
-
-Resource events are sent out via the OSGi Event Admin. You can subscribe to those event by registering an OSGi service for [`org.osgi.service.event.EventHandler`][8]. Several properties should be used to restrict the subscription to only the relevant event. The event topics which are used for resources are listed as constants in [`org.apache.sling.api.SlingConstants`][9] starting with the prefix `TOPIC_`.
-
-## Wrap/Decorate Resources
-
-The Sling API provides an easy way to wrap or decorate a resource before returning. Details see [Wrap or Decorate Resources](/documentation/the-sling-engine/wrap-or-decorate-resources.html).
-
-
-[1]: http://sling.apache.org/apidocs/sling8/org/apache/sling/api/resource/ResourceMetadata.html "ResourceMetadata"
-[2]: http://sling.apache.org/apidocs/sling8/org/apache/sling/api/resource/Resource.html "Resource"
-[3]: http://sling.apache.org/apidocs/sling8/org/apache/sling/api/resource/AbstractResource.html "AbstractResource"
-[4]: https://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/resourceprovider/
-[5]: https://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/serversidetests/WriteableResourcesTest.java
-[6]: https://svn.apache.org/repos/asf/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
-[7]: https://svn.apache.org/repos/asf/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ExternalResourceChangeListener.java
-[8]: https://osgi.org/javadoc/r6/cmpn/org/osgi/service/event/EventHandler.html
-[9]: http://sling.apache.org/apidocs/sling8/org/apache/sling/api/SlingConstants.html