sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bdelacre...@apache.org
Subject [2/3] sling-site git commit: Readd the old-stuff folder
Date Mon, 26 Jun 2017 12:40:45 GMT
Readd the old-stuff folder


Project: http://git-wip-us.apache.org/repos/asf/sling-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/sling-site/commit/2d8c7ce5
Tree: http://git-wip-us.apache.org/repos/asf/sling-site/tree/2d8c7ce5
Diff: http://git-wip-us.apache.org/repos/asf/sling-site/diff/2d8c7ce5

Branch: refs/heads/master
Commit: 2d8c7ce5592b8dac8e95209877c61febce4ca948
Parents: 060b0c9
Author: Bertrand Delacretaz <bdelacretaz@apache.org>
Authored: Mon Jun 26 14:40:06 2017 +0200
Committer: Bertrand Delacretaz <bdelacretaz@apache.org>
Committed: Mon Jun 26 14:40:06 2017 +0200

----------------------------------------------------------------------
 content/old-stuff/assembly.md                   | 126 ++++++++++
 content/old-stuff/launch-sling.md               |   6 +
 content/old-stuff/request-processing.md         | 172 +++++++++++++
 .../run-modes-org-apache-sling-runmode.md       |  51 ++++
 content/old-stuff/scriptengineintegration.md    |  13 +
 .../scriptengineintegration/groovy-support.md   |  68 +++++
 .../xslt-processing-pipeline.md                 | 183 ++++++++++++++
 content/old-stuff/servlet-resolution.md         | 174 +++++++++++++
 content/old-stuff/sling-api.md                  | 245 +++++++++++++++++++
 content/plugins.md                              |  10 -
 10 files changed, 1038 insertions(+), 10 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/assembly.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/assembly.md b/content/old-stuff/assembly.md
new file mode 100644
index 0000000..6870c4c
--- /dev/null
+++ b/content/old-stuff/assembly.md
@@ -0,0 +1,126 @@
+title=Assembly
+type=page
+status=published
+~~~~~~
+The Assembly concept grew out of a need to bundle together a set of OSGi Bundles to deploy applications. The concept has been developped before the OSGi Deployment Package Service Specification has been published in the Release 4.1 Compendium Services Specification. It will have to be discussed whether the Assembly concept is dropped in favor of the Deplyoment Package Service.
+
+## Introduction
+
+This chapter discusses the units of deployment as well as the units of functionality. The following contents is based on the Module and Service specifications of the OSGi Service Platform Core Specification, Release 4 but enhances functionality for ease of use and in terms of best practices.
+
+The term *Units of Deployment* describes the idea of packaging up functionality implemented by Java Classes into modules, so called *Bundles*. For bigger and more complicated applications the fine grained modularity of *Bundles* may be to complicated, so this chapter proposes an extension called *Assembly*. The goal of the *Assembly* specification presented below is to provide functionality to delivery a collection of bundles belonging together.
+
+The term *Units of Functionality* describes the idea of providing services implemented by Java Classes, so called *Services*. A *Service* is an abstraction and does not actually prescribe the implementation of specific interfaces. Instead the OSGi specification states how functionality may be provided to clients by registering objects implementing interfaces defining the functionality in terms of a Java API.
+
+
+
+## Bundles
+
+The core unit of deployment is the *Bundle*. The OSGi core specification defines a *Bundle* to be a Java Archive (JAR) file whose manifest - the `META-INF/MANIFEST.MF` file - contains specific headers identifying the bundle. Most manifest headers are optional with defined default values - only the `Bundle-SymbolicName` header is actually required and the `Bundle-ManifestVersion` header should be set to `2` to identify the bundle to be a R4 bundle. Other information defined in the manifest is the bundle version, the list of packages exported - provided to other bundles - and imported - used and required to be provided by other bundles. See chapter *3.2.1 Bundle Manifest Header* of the OSGi Service Platform Core Specification for a complete list of the defined bundle manifest headers.
+
+Bundles may be installed, updated , started, stopped and removed in an OSGi framework individually.
+
+
+
+## Assemblies
+
+For the deployment of bigger systems, the number of bundles may increase very quickly. To ease the management of products consisting of multiple bundles, this chapter introduces the *Assembly*. An Assembly is simply a collection of bundles deployed together. An Assembly - like a Bundle - is a JAR file whose manifest contains specific headers. In fact, an Assembly is just a standard bundle, with additional functionality.
+
+Assemblies are managed by the *Assembly Manager* which itself is a bundle installed into the framework.
+
+
+
+### Assembly manifest headers
+
+As an Assembly is a standard Bundle, all the defined Bundle manifest headers may be specified. In addition, for the *Assembly Manager* to recognize an assembly and for the OSGi Bundle Repository to support dependency resolution, the following manifest headers are defined. All headers are optional with documented default values except where noted.
+
+* **Assembly-Bundles** - The list of bundles contained in this assembly. See below for the definition of the syntax of this header. This header is required. The presence of this headers identifies an Assembly to the *Assembly Manager*.
+* **Assembly-BundleRepository** - A comma-separated list of URLs pointing to OSGi Bundle Repository descriptors. These bundle repositories will be used to install bundles listed in the `Assembly-Bundles` header. This header is optional with not default value.
+
+
+
+### Assembly Lifecycle
+
+An Assembly, like all bundles, may be in any of the defined bundle states:
+
+* **Installed** - The Assembly bundle has been installed into the system but not yet resolved. The *Assembly Manager* will try to install all bundles listed in the `Assembly-Bundles` header. The start levels of the bundles will be set according to the `startlevel` parameter. The bundles will not be started. If installation of one or more of the bundles fails, *Assembly Manager* logs an error message.
+* **Resolved** - The Assembly bundle is resolved, that is all imported packages are wired into the framework. The *Assembly Manager* does not handle this state change, rather the installed bundles will be resolved by the framework either automatically after installation or when started later.
+* **Started** - The Assembly bundle has been started by calling the `Bundle.start()` method. The *Assembly Manager* will start all newly installed and resolved bundles. Depending on the start level set on the bundle(s) and the current system start level, the bundles will only be permanently marked to start while actually starting the bundles may be delayed until the system enters the respective start level. If any bundle fails to start, an error message is logged.
+* **Stopped** - The Assembly bundle has been stopped by calling the `Bundle.stop()` method. All bundles belong to the Assembly and linked to the Assembly are also stopped.
+* **Unresolved** - The Assembly bundle has been unresolved by the system for any reason, possibly any missing dependencies. Assembly bundles entering this state are ignored by the *Assembly Manager*.
+* **Uninstalled** - The Assembly bundle is being uninstalled by calling the `Bundle.uninstall()` method. The *Assembly Manager* will (try to) uninstall all bundles listed in the `Assembly-Bundles` header.
+* **Updated** - The Assembly bundle will update all bundles installed previously according to the `Assembly-Bundles` header. If this header omits any bundle listed in the previous bundle version, the respective bundle is uninstalled from the system. If a bundle is already installed with the correct version, the installed bundle is not touched (It may though be uninstalled together with the Assembly Bundle if the Assembly Bundle is uninstalled).
+
+
+
+### Bundles referenced by multiple Assembly Bundles
+
+It is conceivable, that bundles are listed in the `Assembly-Bundles` header of more than one Assembly Bundle. If this is the case, the following collision resolution takes place:
+
+   * If the version of the bundle installed by the first Assembly bundle handled matches the version specification of any later Assembly Bundle, the installed bundle is not touched. Otherwise, if the later Assembly Bundle lists a version specification, which is acceptable for the first Assembly Bundle, the installed bundle is updated to the required version. If the version specifications may not be matched one way or the other, the later Assembly Bundle fails to install.
+   * If the bundle is installed with a defined start level, the later Assembly Bundle will not overwrite the already set start level. If the start level has not been set yet it is set to the specified start level.
+   * Bundles installed through Assembly Bundles remain installed as long as there is at least one Assembly Bundle listing the bundle in the `Assembly-Bundles` header. As soon as there is no referring Assembly Bundle anymore, the bundle is uninstalled.
+   * Bundles not referred to by any Assembly Bundle are ignored by the *Assembly Manager*.
+   * Bundles installed through the *Assembly Manager* may be updated and/or uninstalled independently from their defining Assembly Bundle. If a bundle has been installed it will be reinstalled the next time the Assembly Bundle enters the *installed* state. If a bundle has been updated, it is not touched by the *Assembly Manager* as long as the updated version matches the version specification of the Assembly Bundle.
+
+
+
+### Bundle Installation
+
+When an Assembly is installed into the framework, the *Assembly Manager* checks to see whether the Assembly needs to be deployed. This is done by checking the bundles listed in the `Assembly-Bundles` header whether they are installed or not. All bundles not installed will be installed and started if requested so.
+
+The following BNF defines the syntax =Assembly-Bundles= header value:
+
+
+    Assembly-Bundles = Bundle { "," Bundle } .
+    Bundle = Symbolic-Name { ";" Parameter } .
+    Symbolic-Name = // The Bundle symbolic name 
+    Parameter = ParameterName "=" ParameterValue .
+
+
+To control the selection and installation of bundles, the following parameters may be used:
+
+* **version** - The version of the bundle to install. This is a version range specification as per chapter 3.2.5 Version Ranges of the OSGi core specification. When this parameter is declared as a single version - eg. *1.2.3* - it is interpreted as the version range *\[1.2.3,&infin;)*. The default value is *\[0.0.0,&infin;)* to install the most recent version of the bundle available.
+* **startlevel** - The start level to set for the bundle. This may be any positive integer value. Default value is undefined to use the current initial bundle start level of the framework.
+* **entry** - The path of the Assembly Bundle entry providing the data to be installed.
+* **linked** - Defines whether the bundle should be started and stopped together with the Assembly to which the bundle belongs. Default value is `true`.
+
+If resolving the bundles results in more bundles to be downloaded from the bundle repository to resolve the dependency, these bundles are always automatically started and assigned a startlevel which is smaller than the smallest startlevel of any of the bundles listed.
+
+
+### Bundle Location
+
+Generally bundles to be installed with an Assembly Bundle are retrieved from an OSGi Bundle Repository. The `Assembly-BundleRepository` header may list additional URLs which will be temporarily used to resovle the bundles. Otherwise the system default bundle repositories will be used only.
+
+If a bundle is defined in the `Assembly-Bundles` header with an `entry` parameter, the respective entry is first looked for in the Assembly Bundle. If the entry exists, it is used as the bundle source to install. If no `entry` parameter is present for a declared bundle or the entry is missing, the OSGi Bundle Repository is used.
+
+Restrictions when packaging bundles with the Assembly:
+
+* **Dependency Resolution** - Any missing dependencies of the bundles to be installed will not be resolved. That is, if the bundles fail to resolve, the Assembly fails to install.
+* **`version` Parameter** - The `version` parameter of the bundle installation declaration is ignored because any JAR file whose name matches the bundle symbolic name to be installed, is installed.
+
+If the `Assembly-BundleRepository` header contains a comma-separated list of URL to OSGi Bundle Repository descriptors and the OSGi Bundle Repository Service is available in the framework, the bundles declared in the `Assembly-Bundles` header are resolved through the OSGi Bundle Repository Service using the URL from the `Assembly-BundleRepository` header.
+
+If the bundles declare any dependencies, which may not be resolved by bundles already installed in the framework or by any of the bundles to be installed, the OSGi Bundle Repository is used to try to resolve these missing dependencies. If this resolution succeeds, installation of the Assembly succeeds. Any bundles not declared in the Assembly but installed due to this dependency resolution will not be assumed to belong to the Assembly. Hence, these bundles will not be uninstalled (or updated) if the Assembly is uninstalled (or updated).
+
+* **Example** - Assume the `Assembly-Bundles` header is set to `org.apache.sling.sample1;entry=path.jar,org.apache.sling.sample2`. The bundle `org.apache.sling.sample1` is then installed from the Assembly Bundle entry `path.jar`, while the bundle `org.apache.sling.sample2` is resolved in the OSGi Bundle Repository.
+
+
+
+
+## Best Practices
+
+
+### Size of Bundles
+
+There is no fixed formula to calculate the best size for a bundle: It all depends on the contents and the intentions of the bundle and its programmer. The following list provides some hints:
+
+   * For ease of development follow the idea of *One Bundle - One Project*
+   * Don't pack too much into a bundle but do not pack a single class into a bundle (unless you have a very good reason of course :-) )
+   * Do not mix and match everything into a bundle. Rather bundle things together which belong together, for example create separate bundles for a HTTP Client implementation and DB support classes
+   * Use similar heuristics to decide on the contents of a bundle as you would for the contents of a plain old JAR file.
+
+
+### Nomen est Omen
+
+The symbolic name of a bundle should reflect its contents. A bundle should generally only contain a single subtree in the virtual package tree. The symbolic name of the bundle should be the root package contained within. For example, consider a bundle containing the packages `org.apache.sling.sample`, `org.apache.sling.sample.impl`, `org.apache.sling.more`. The bundle would the be named `org.apache.sling.sample`.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/launch-sling.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/launch-sling.md b/content/old-stuff/launch-sling.md
new file mode 100644
index 0000000..5064d70
--- /dev/null
+++ b/content/old-stuff/launch-sling.md
@@ -0,0 +1,6 @@
+title=Launch Sling
+type=page
+status=published
+~~~~~~
+
+Please refer to [The Sling Launchpad]({{ refs.the-sling-launchpad.path }}) for up-to-date information on launching Sling.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/request-processing.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/request-processing.md b/content/old-stuff/request-processing.md
new file mode 100644
index 0000000..01755cc
--- /dev/null
+++ b/content/old-stuff/request-processing.md
@@ -0,0 +1,172 @@
+title=Request Processing
+type=page
+status=published
+~~~~~~
+
+<div class="note">
+2008-02-13: this page is *out of sync* with the current codebase, needs to be reviewed and updated.
+</div>
+
+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.
+
+
+## Core Request Processing
+
+
+The HTTP request enters Sling in the `org.apache.sling.core.ComponentRequestHandlerImpl.service(ServletRequest req, ServletResponse res)` method as the `ComponentRequestHandlerImpl` is registered as the Servlet handling HTTP requests. This method sets up the initial `ComponentRequest` and `ComponentResponse` objects and hands the request over to the first `ComponentFilterChain`. This first filter chain calls all `ComponentFilter` instances registered as request level filters. After processing all filters in the request level filter chain, the request is handed over to the second `ComponentFilterChain` which calls all `ComponentFilter` instances registered as component level filters. At the end of the second filter chain the `service` method of the actual `Component` to which the request resolved is called.
+
+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 `RequestDispatcher.include` method. If the request dispatcher dispatches to a `Content` object Sling will hand the dispatch request over to the component level filter chain, which at the end will call the `service` method for the `Content` object to dispatched to. This process may be repeated at the component's discretion only limited by processing resources such as available memory.
+
+
+As can be seen Sling itself is absed on the Component API `ComponentFilter` mechanism. As such Sling provides and uses the following filters in the Sling Core bundle:
+
+{table:class=confluenceTable}
+{tr}{th:colspan=2|class=confluenceTh} Request Level Filters {th}{tr}
+{tr}{td:class=confluenceTd} `ErrorHandlerFilter` {td}{td:class=confluenceTd} Handles exceptions thrown while processing the request as well implements the `ComponentResponse.sendError()` method {td}{tr}
+{tr}{td:class=confluenceTd} `AuthenticationFilter` {td}{td:class=confluenceTd} Implements authentication for the request and provides the JCR Session of the request {td}{tr}
+{tr}{td:class=confluenceTd} `BurstCacheFilter` {td}{td:class=confluenceTd} Checks whether the request may be handled by cached response data {td}{tr}
+{tr}{td:class=confluenceTd} `LocaleResolverFilter` {td}{td:class=confluenceTd} Provides information on the `Locale` to be used for request processing. This filter implements the `ComponentRequest.getLocale()` method {td}{tr}
+{tr}{td:class=confluenceTd} `ThemeResolverFilter` {td}{td:class=confluenceTd} Provides the `Theme` for the request. The theme is provided as a request attribute {td}{tr}
+{tr}{td:class=confluenceTd} `URLMapperFilter` {td}{td:class=confluenceTd} Resolves the request URL to a JCR Node which may be mapped into a `Content` object {td}{tr}
+{tr}{td:class=confluenceTd} `ZipFilter` {td}{td:class=confluenceTd} Sample filter showing how the request response might be compressed according to the *Accept-Encoding* request header. This filter is not enabled by default. {td}{tr}
+{table}
+
+
+
+Deducing from these lists of filters, the actual request processing can be refined into the following steps:
+
+1. 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.
+1. 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 `Component` instances called during request processing decide to signal non-cacheability for whatever reason, the response data will of course not cached.
+1. Extract the `java.util.Locale` 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.
+1. Find the theme (or skin) to use to render the response. This step will add a `org.apache.sling.theme.Theme` object as a request parameter, which may be used by `Component`s to decide on specific rendering. For example, the theme may encapsulate information on the CSS to use for responses rendered as HTML.
+1. Resolve the request URL into a `Content` object.
+
+
+The default request level filter chain setup ends with finding the `Content` 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 `Content` instance. As such, the component level filter chain is used for each `Content` 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.
+
+
+{table:class=confluenceTable}
+{tr}{th:colspan=2|class=confluenceTh} Component Level Filters {th}{tr}
+{tr}{td:class=confluenceTd} `CacheFilter` {td}{td:class=confluenceTd} Checks whether the request to the current `Content` object may be handled by cached response data {td}{tr}
+{tr}{td:class=confluenceTd} `ComponentResolverFilter` {td}{td:class=confluenceTd} Resolves the component ID returned by the `Content.getComponentId()` method into a `Component` instances, which will be called to service the request {td}{tr}
+{table}
+
+Again, deducing from the list of filters, the following steps are taking to service a given `Content` object:
+
+1. Check whether the `Content` object processing may be handled from the cache. Same as with request level cache handling, a cache entry may exist for a single `Content` 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 `Content` object. Otherwise processing continues and may optionally lead to a new cache entry for the `Content` object to be reused later.
+1. Resolve the component ID returned by the `Content.getComponentId()` method into a `Component` object. Of course it is an error, if the component ID cannot be mapped into a `Component` object.
+
+After resolving the `Component` object default component filter chain terminates and control is handed over to the `service` method of the `Component` object resolved in the last step. At the discretion of the component request dispatchers may now be acquired to render other `Content` objects. In this case the component level filter chain is simply kicked of again resulting in the `service` method of another `Component` being called. And so forth.
+
+
+
+## Resolving Content
+
+As we have seen, the last step in the request level filter chain is the resolution of the request URL into a `Content` object. The URL Mapper Filter implementing this resolution uses an instance of the `org.apache.sling.content.ContentMapper` interface which is acquired by calling the `org.apache.sling.content.jcr.JcrContentManagerFactory` with the repository session acquired by the authentication filter.
+
+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 `/` may be mapped into the default landing page at `/default/home`. The list of such mappings is configurable through the Configuration Admin Service.
+
+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 `/here` might be remapped with the new prefix `/content/there`. The result  of this remapping is then resolved.
+
+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 `ContentManager.load(String)` method is called. This processing terminates if a `Content` object is found or if there is nothing to cut off any more.
+
+This resolution is very simple and straight forwards. Future development may add support for the following features:
+
+* *Vanity URLs* - Map the request URL according to the `Host` request header.
+* *Dynamic Mapping* - Add support for a set of variables in path and/or prefix mapping. For example, a prefix mapping  may contain the string `/content/$\{lang}/$\{user`} resulting in resolving a prefix according to the language of the current locale and the name of the authenticated used.
+
+
+
+## Registering Components
+
+
+The last step of the component level filter chain is resolving the `Component` from the component ID of the `Content` 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 `org.apache.sling.component.Component`. The `ComponentResolverFilter` is listening for these components and registers them internally in a map indexed by the IDs of the component as returned by the `Component.getId()` method.
+
+When a component has to be resolved, the component ID returned by the `Content` 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 [Default Content Mapping and Request Rendering]({{ refs.default-mapping-and-rendering.path }}) page.
+
+
+
+## Reqistering Filters
+
+Just as `Component` instances used by Sling are expected to be registered as OSGi services, the `ComponentFilter`s to be 
+used have to be registered as services under the name `org.apache.sling.component.ComponentFilter`. Sling picks up all registered component filters and adds them to the respective filter chains.
+
+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:
+
+| Property | Description |
+|--|--|
+| `filter.scope` | 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. |
+| `filter.order` | 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. |
+
+
+
+## Content is a Java Object
+
+It is crucial to understand that `Content` is an interface and the request processor of Sling does not actually care, how the `Content` instance comes to live as long as the is such an object and there is a `Component` instance capable of servicing the `Content` object.
+
+By default Sling uses the *URL Mapper* to resolve the request URL into a `Content` object. When a `Component` is tasked with servicing a `Content` object it usually uses the `ComponentRequestDispatcher` to ask Sling to service another content object generally identified by a (relative or absolute) path to a JCR Repository Node from which the `Content` object is loaded.
+
+But instead of having Sling resolve a path into a `Content` object the component may just as well create a `Content` object and hand it over to the `ComponentRequestDispatcher` for service. Consider a request which is handled by a `PageComponent`. This component has to draw a navigation tree somewhere in the response. So the component could of course insist on having a `navigation` child node to dispatch rendering to as follows:
+
+
+
+    RequestDispatcher rd = request.getRequestDispatcher("navigation");
+    rd.include(request, response);
+
+
+
+What happens, though, if there is no `navigation` child node ? Probably, the request will fail with some error status. Of course the component could be more clever and do:
+
+
+
+    Content navigation = request.getContent("navigation");
+    if (navigation != null) {
+        RequestDispatcher rd = request.getRequestDispatcher(navigation);
+        rd.include(request, response);
+    }
+
+
+
+Still, if the `navigation` 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 `Content` object comes to live, the component could do the following:
+
+
+
+    Content navigation = new Content() {
+        public String getPath() {
+            return request.getContent().getPath() + "/navigation";
+        }
+        public String getComponentId() {
+            return NavigationComponent.getClass().getName();
+        }
+    }
+    
+    RequestDispatcher rd = request.getRequestDispatcher(navigation);
+    rd.include(request, response);
+
+
+
+Of course, the page component now has to have knowledge about the actual `Component` to use.
+
+
+Finally, as a further enhancement, the Component might even decide to first check for a `navigation` child node. If such a node does not exist the navigation `Content` object is just created:
+
+
+
+    Content navigation = request.getContent("navigation");
+    if (navigation == null) {
+        navigation = new Content() {
+            public String getPath() {
+                return request.getContent().getPath() + "/navigation";
+            }
+            public String getComponentId() {
+                return NavigationComponent.getClass().getName();
+            }
+        }
+    }
+    
+    RequestDispatcher rd = request.getRequestDispatcher(navigation);
+    rd.include(request, response);
+
+
+
+This could for example be used to fall back to a default navigation setup while providing for specialized navigation configuration in an optional `navigation` child node.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/run-modes-org-apache-sling-runmode.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/run-modes-org-apache-sling-runmode.md b/content/old-stuff/run-modes-org-apache-sling-runmode.md
new file mode 100644
index 0000000..b492e73
--- /dev/null
+++ b/content/old-stuff/run-modes-org-apache-sling-runmode.md
@@ -0,0 +1,51 @@
+title=Run Modes
+type=page
+status=published
+~~~~~~
+
+<div markdown="1" class="note">
+As of Sling 6 the <code>org.apache.sling.runmode</code> bundle is replaced
+by the new <a href="/documentation/bundles/sling-settings-org-apache-sling-settings.html">Sling Settings (org.apache.sling.settings)</a>
+Bundle. For backwards compatibility this bundle may still exist in your environment. New code should use the API of the new
+Sling Settings Bundle, though.
+</div>
+
+# Overview
+
+Run modes are meant to define different sets of configuration parameters for various Sling instances.
+
+In a web publishing environment, for example, one could use run modes like *staging, production, dev, dmz* or combinations of such values.
+
+The *[org.apache.sling.runmode]({{ refs.http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/runmode.path }})* bundle provides a simple way of defining and querying a list of run modes.
+
+# Installation
+
+The run mode service is not present in the default Sling launchpad builds, to activate it install and start the *org.apache.sling.runmode* bundle.
+
+# Configuration
+
+Run modes can only be configured using a system property, or via the *sling.properties* file.
+
+Using *-Dsling.run.modes=foo,bar* on the JVM command-line, for example, activates the *foo* and *bar* run modes. 
+
+This command-line parameter takes precedence over a similar definition (*sling.run.modes=dev,staging*) that might be present in the *sling.properties* file found in the Sling home directory.
+
+# Getting the current list of run modes
+
+The [RunMode service]({{ refs.http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/runmode/src/main/java/org/apache/sling/runmode/RunMode.java.path }}) provides the current list of run modes, examples:
+
+    :::java
+    RunMode r = ...get from BundleContext...
+    String [] currentRunModes = r.getCurrentRunModes();
+    
+    String [] expectedRunModes = { "foo", "wii" };
+    if(r.isActive(expectedRunModes)) {
+      // at least one of (foo,wii) run modes
+      // is active
+    }
+
+
+# See also
+
+The RunMode service is used by the [jcrinstall]({{ refs.jcr-installer-provider.path }}) services.
+

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/scriptengineintegration.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/scriptengineintegration.md b/content/old-stuff/scriptengineintegration.md
new file mode 100644
index 0000000..af8b738
--- /dev/null
+++ b/content/old-stuff/scriptengineintegration.md
@@ -0,0 +1,13 @@
+title=Integrating Scripting Languages
+type=page
+status=published
+~~~~~~
+
+This page should be extended with more concrete and detailed information. For now, we have the following information:
+
+* 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.
+* From a mail on the mailing list, this is a very condensed how-to:
+      * Create the ScriptEngineFactory implementation
+      * Create a bundle comprising the above implementation as well as the script language implementation.
+      * Create the `META-INF/services/javax.script.ScriptEngineFactory` file listing the fully qualified name of your ScriptEngineFactory implementaiton
+

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/scriptengineintegration/groovy-support.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/scriptengineintegration/groovy-support.md b/content/old-stuff/scriptengineintegration/groovy-support.md
new file mode 100644
index 0000000..2e6f356
--- /dev/null
+++ b/content/old-stuff/scriptengineintegration/groovy-support.md
@@ -0,0 +1,68 @@
+title=Groovy Support
+type=page
+status=published
+~~~~~~
+
+After meeting Paul King of the Groovy Team at Apache Con US 08 in New Orleans, I set out to take a stab at SLING-315 again to add Groovy support to Sling. It turned out, that the current Groovy 1.6 branch already contains the required setup to build the `groovy-all.jar` as an OSGi Bundle, which is directly usable with Sling by just installing that bundle.
+
+Currently the Groovy team is working hard towards the 1.6 release and many things are in flux, which is really great.
+
+So, on 11. Dec. 2008 Paul King of the Groovy Team has deployed a [first RC1 Snapshot of Groovy 1.6]({{ refs.http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/1.6-RC-1-SNAPSHOT/groovy-all-1.6-RC-1-20081211.113737-1.jar.path }}) which contains all the required OSGi bundle manifest headers as well das the JSR-233 `ScriptEngine` to use the `groovy-all.jar` unmodified with Sling. So just go ahead, grab the Groovy-All 1.6 RC 1 SNAPSHOT deploy it into your Sling instance and enjoy the fun of Groovy.
+
+If you want to be on verge of development, you might want to go for Groovy 1.7: The second SNAPSHOT of beta-1 also contains the required headers and classes and may as well be used unmodified in Sling. You may download it here: `[groovy-all-1.7-beta-1-20081210.120632-2.jar]({{ refs.http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/1.7-beta-1-SNAPSHOT/groovy-all-1.7-beta-1-20081210.120632-2.jar.path }})`.
+
+
+To deploy the bundle go to the Bundles page, for example at http://localhost:8888/system/console/bundles of the Apache Felix Web Console select the bundle file to upload, check the *Start* check box and click *Install or Update* button.
+
+You may check, whether the Groovy ScriptEngine has been "accepted" by Sling, by going to the Script Engines page of the Apache Felix Web Console. You should see the entry for Groovy there, somthing like this:
+
+
+    Groovy Scripting Engine, 2.0
+      Language      Groovy,
+      Extensions    groovy
+      MIME Types    application/x-groovy
+      Names         groovy, Groovy
+
+
+
+## Testing
+
+To test create a simple Groovy script, for example
+
+
+    response.setContentType("text/plain");
+    response.setCharacterEncoding("UTF-8");
+    
+    println "Hello World !"
+    println "This is Groovy Speaking"
+    println "You requested the Resource ${resource} (yes, this is a GString)"
+
+
+and upload it to the repository as `/apps/nt/folder/GET.groovy` using your favourite WebDAV client or use curl to upload the file (assuming Sling is running on localhost:8888) :
+
+
+    $ curl -u admin:admin -FGET.groovy=@GET.groovy -F../../nt/jcr:primaryType=sling:Folder http:host:8888/apps/nt/folder
+
+
+To test it create a `/sample` `nt:Folder` node using your favourite WebDAV client or use curl again:
+
+
+    $ curl -u admin:admin -Fjcr:primaryType=nt:folder http://localhost:8888/
+
+
+
+Finally, request the `/sample` node using your favourite Browser or use curl again:
+
+
+    $ curl http://localhost:8888/sample
+    Hello World !
+    This is Groovy Speaking
+    You requested Resource JcrNodeResource, type=nt:folder, path=/sample (yes, this is a GString)
+
+
+
+## References
+
+* [SLING-315]({{ refs.https://issues.apache.org/jira/browse/SLING-315.path }}) -- The initial Sling issue proposing the addition of a Groovy ScriptEngine to Sling.
+* [Groovy Support in Apache Sling]({{ refs.http://markmail.org/message/7sqscr5y2mbk6jko.path }}) -- A short thread on turning the Groovy `groovy-all.jar` into an OSGi Bundle.
+* [Groovy in Apache Sling]({{ refs.http://markmail.org/message/47n2ow2jlo553jvk.path }}) -- Thread on adding the `DynamicImport-Package` header to the Groovy bundle manifest.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/scriptengineintegration/xslt-processing-pipeline.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/scriptengineintegration/xslt-processing-pipeline.md b/content/old-stuff/scriptengineintegration/xslt-processing-pipeline.md
new file mode 100644
index 0000000..3d201e8
--- /dev/null
+++ b/content/old-stuff/scriptengineintegration/xslt-processing-pipeline.md
@@ -0,0 +1,183 @@
+title=XSLT Processing Pipeline
+type=page
+status=published
+~~~~~~
+
+In the *Apache Sling Scripting W3C XML Processing Support* bundle, Juanjo Vàzquez has implemented XSLT processing support for Sling as another new scripting engine, based on the [Cocoon 3 pipeline engine](http://cocoon.apache.org/3.0/).
+
+## Intro
+
+An XML pipeline specifies a sequence of operations to be performed on zero or more XML documents. There are a number of advantages to using pipelines above all in terms of separation of concerns. On the other hand, we talk about XSLT processing if the operations in a pipeline are performed executing or applying XSLT stylesheets.
+
+XSLT processing support is implemented in Sling as an scripting engine bundle named *Apache Sling Scripting W3C XML Processing Support*. This bundle is based on the [Cocoon 3 pipeline engine](http://cocoon.apache.org/3.0/) and uses the [W3C XProc language](http://www.w3.org/TR/xproc/) in order to specify pipelines to be processed.
+
+For the time being, XProc is partially implemented and it is not clear that Sling must support all W3C recomendation yet. This could depend of concrete user requirements or use cases.
+
+The source code is found in the [contrib/scripting/xproc](http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc) module.
+
+## How to Install
+
+Install the `org.apache.sling.scripting.xproc` bundle in order to work with XProc. You can achieve this either building it from `contrib/scripting/xproc` folder in the Sling trunk or by downloading it from the Apache Snapshot repository here: [org.apache.sling.scripting.xproc-2.0.0-incubator-20090403.114403-1.jar](http://people.apache.org/repo/m2-snapshot-repository/org/apache/sling/org.apache.sling.scripting.xproc/2.0.0-incubator-SNAPSHOT/org.apache.sling.scripting.xproc-2.0.0-incubator-20090403.114403-1.jar).
+
+To deploy the bundle go to the bundles page of Apache Felix Web Console (http://localhost:8888/system/console/bundles), select the bundle file to upload, check the Start check box and click Install or Update button.
+
+In order to check whether XProc scripting engine has been installed, go to the Script Engines page of the Apache Felix Web Console and see the entry for XProc there:
+
+
+    Apache Sling Scripting W3C XML Processing Support, 2.0.0-incubator-SNAPSHOT
+      	Language 	XMLProc, 1.0
+      	Extensions 	xpl
+      	MIME Types 	application/xml
+      	Names 	XProc, xml processing, xml pipeline processor 
+
+
+## How it works
+
+As explained above, the bundle is able to perform a sequence of XSLT transforms on an XML document just as is expressed in a pipeline definition. A pipeline definition is a file with an xpl extension that follows the [W3C XProc grammar](http://www.w3.org/TR/xproc/). Only `p:xslt` steps are supported at the moment.
+
+For the XML input of pipeline, the processing uses a Cocoon generator named `SlingGenerator` that tries to resolve the requested resource as (in order of preference):
+
+* a static XML file 
+* a dynamically generated XML 
+* the underlying node's export document view 
+
+## Samples
+
+Let's see some samples in order to understand the processing behaviour.
+
+1. Create some content
+
+        #!bash
+        $ curl -u admin:admin -F sling:resourceType=xproc -F title="some title" \
+        -F text="And some text" http://localhost:8888/foo
+
+2. Use WebDAV or curl to create a pipeline script at `/apps/xproc/xproc.xpl` :
+
+        #!xml
+        <?xml version="1.0" encoding="UTF-8"?>
+        <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
+        
+          <p:xslt>
+            <p:input port="stylesheet">
+              <p:document href="/apps/xproc/one.xsl"/>
+            </p:input>
+          </p:xslt>
+        
+          <p:xslt>
+            <p:input port="stylesheet">
+              <p:document href="/apps/xproc/two.xsl"/>
+            </p:input>
+          </p:xslt>
+        
+        </p:pipeline>
+
+3. Store the XSLT transforms in the repository:
+
+    **`/apps/xproc/one.xsl`**
+    
+        #!xml
+        <xsl:stylesheet version="1.0"
+            xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+        
+            <xsl:template match="/">
+              <one>
+                <xsl:copy-of select="."/>
+              </one>
+            </xsl:template>
+        
+        </xsl:stylesheet>
+
+    **`/apps/xproc/two.xsl`**
+    
+        #!xml
+        <xsl:stylesheet version="1.0"
+            xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+        
+            <xsl:template match="/">
+              <two>
+                <xsl:copy-of select="."/>
+              </two>
+            </xsl:template>
+        
+        </xsl:stylesheet>
+
+4. Request foo.html to execute the pipeline:
+
+        #!bash
+        $ curl http://admin:admin@localhost:8888/foo.html
+        
+        <?xml version="1.0" encoding="UTF-8"?>
+        <two>
+          <one>
+            <foo ...sling:resourceType="xproc" text="And some text" title="some title"/>
+          </one>
+        </two>
+
+    In this case, the node's document view has been the pipeline's source.
+
+5. Now, store a static XML in the repository at `/foo.xml`:
+    
+        #!xml
+        <?xml version="1.0" encoding="UTF-8"?>
+        <foo>
+        	<content>
+        		foo: static content
+        	</content>
+        </foo>
+
+    
+6. Again, request foo.html to execute the pipeline:
+
+        #!bash
+        $ curl http://admin:admin@localhost:8888/foo.html
+        
+        <?xml version="1.0" encoding="UTF-8"?>
+        <two>
+          <one>
+            <foo>
+            	<content>
+            	  foo: static content
+            	</content>
+            </foo>
+          </one>
+        </two>
+    
+    This time the pipeline's source has been a static XML file.
+    
+7. Store a script in the repository at `/apps/xproc/xproc.xml.esp`
+    
+        #!xml
+        <?xml version="1.0" encoding="UTF-8"?>
+        <foo>
+        	<content>
+        		foo: dynamic content
+        	</content>
+        </foo>
+
+
+8. Delete the previously created static xml file `/foo.xml`.
+
+9. Request foo.html to execute the pipeline:
+
+        #!bash
+        $ curl http://admin:admin@localhost:8888/foo.html
+        
+        <?xml version="1.0" encoding="UTF-8"?>
+        <two>
+          <one>
+            <foo>
+            	<content>
+            	  foo: dynamic content
+            	</content>
+            </foo>
+          </one>
+        </two>
+
+    This time the pipeline's source has been a dinamically generated XML.
+
+## References
+
+* [Cocoon 3 pipeline engine](http://cocoon.apache.org//3.0/)
+* [W3C XProc language](http://www.w3.org/TR/xproc/)
+* [SLING-893](https://issues.apache.org/jira/browse/SLING-893)
+* [Mail list discussion](http://markmail.org/thread/33h5nhk5e3mswrue)

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/servlet-resolution.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/servlet-resolution.md b/content/old-stuff/servlet-resolution.md
new file mode 100644
index 0000000..a13d0f4
--- /dev/null
+++ b/content/old-stuff/servlet-resolution.md
@@ -0,0 +1,174 @@
+title=Servlet Resolution
+type=page
+status=published
+~~~~~~
+<div class="warning">
+Please note that the description on this page is out of sync with the most recent developments going on as part of implementing issue [SLING-387]({{ refs.https://issues.apache.org/jira/browse/SLING-387.path }}). See the links to integration tests at the end of this page for the Current Truth.
+
+Please see the new [Servlets]({{ refs.servlets.path }}) page.
+</div>
+
+[TOC]
+
+
+## Servlets are Resources
+
+As explained on the [Resources]({{ refs.resources.path }}) 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 `ResourceResolver`.
+
+To show a Servlet inside the Resource tree, the `sling/servlet-resolver` project provides a `ServletResourceProvider` implementing the `ResourceProvider` interface. For each Servlet registered as an OSGi service with one or more defined service reference properties a `ServletResourceProvider` instance is registered.
+
+The following service reference properties are defined for Servlets defined as OSGi services of type `javax.servlet.Servlet`:
+
+| Name | Description |
+|--|--|
+| `sling.servlet.paths` | 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. |
+| `sling.servlet.resourceTypes` | 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. |
+| `sling.servlet.selectors` |  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. |
+| `sling.servlet.extensions` | 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. |
+| `sling.servlet.methods` |  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. |
+| `sling.servlet.prefix` |  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. |
+
+
+For a Servlet registered as an OSGi service to be used by the Sling Servlet Resolver, the following restrictions apply:
+
+1. Either the `sling.servlet.paths` or the `sling.servlet.resourceTypes` service reference property must be set. If neither is set, the Servlet service is ignored.
+1. If the `sling.servlet.paths` property is set, all other `sling.servlet.*` properties are ignored.
+1. Otherwise a Resource provider is registered for the Servlet for each permutation resource types, selectors, extensions and methods.
+
+
+Each path to be used for registration -- either from the `sling.servlet.paths` property or constructed from the other `sling.servlet.*` properties -- must be absolute. Any relative path is made absolute by prefixing it with a root path. This prefix may be set with the `sling.servlet.prefix` service registration property. If this property is not set, the first entry in the `ResourceResolver` search path for the `ResourceResolver.getResource(String)` method is used as the prefix. If this entry cannot be derived, a simpe slash -- `/` -- is used as the prefix.
+
+
+### Example: Registration by Path
+
+
+    sling.servlet.paths = [ "/libs/sling/sample/html", "/libs/sling/sample/txt" ]
+    sling.servlet.resourceTypes = [ "sling/unused" ]
+    sling.servlet.selectors = [ "img" ]
+    sling.servlet.extensions = [ "html", "txt", "json" ]
+
+
+A Servlet service registered with these properties is registered under the following paths:
+
+   * `/libs/sling/sample/html`
+   * `/libs/sling/sample/txt`
+
+The registration properties `sling.servlet.resourceTypes`, `sling.servlet.selectors` and `sling.servlet.extensions` are ignored because the `sling.servlet.paths` property is set.
+
+
+### Example: Registration by Resource Type etc.
+
+
+    sling.servlet.resourceTypes = [ "sling/unused" ]
+    sling.servlet.selectors = [ "img", "tab" ]
+    sling.servlet.extensions = [ "html", "txt", "json" ]
+
+
+A Servlet service registered with these properties is registered under the following paths:
+
+   * `*prefix*/sling/unused/img/html`
+   * `*prefix*/sling/unused/img/txt`
+   * `*prefix*/sling/unused/img/json`
+   * `*prefix*/sling/unused/tab/html`
+   * `*prefix*/sling/unused/tab/txt`
+   * `*prefix*/sling/unused/tab/json`
+
+As explained the script is registered for each permutation of the resource types, selectors and extension. See above For an explanation of how `*prefix*` is defined.
+
+
+## Scripts are Servlets
+
+
+The Sling API defines a `SlingScript` interface which is used to represent (executable) scripts inside of Sling. This interface is implemented in the `scripting/resolver` bundle in the `DefaultSlingScript` class which also implements the `javax.servlet.Servlet`.
+
+To further simplify the access to scripts from the Resource tree, the `scripting/resolver` bundle registers an `AdapterFactory` to adapt Resources to Scripts and Servlets. In fact the adapter factory returns instances of the `DefaultSlingScript` class for both Scripts and Servlets.
+
+This functionality is used by the `ServletResolver.resolveServlet` implementation in the `sling/servlet-resolver` 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 `javax.servlet.Servlet` is used for processing the resource.
+
+So from the perspective of the Servlet resolver, scripts and servlets are handled exactly the same.
+
+
+## Resolution Process
+
+The Servlet Resolution Process four elements of a `SlingHttpServletRequest`:
+
+1. The *resource type* as retrieved through `request.getResource().getResourceType()`. Because the resource type may be a node type such as *nt:file*, 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.
+1. The *request selectors* as retrieved through `request.getRequestPathInfo().getSelectorString()`. The selector string is turned into a realtive path by replacing all separating dots by forward slashes. For example the selector string `print.a4` is  converted into the relative path `print/a4`.
+1. The *request extension* as retrieved through `request.getRequestPathInfo().getExtension()` if the request method is *GET* or *HEAD* and the request extension is not empty.
+1. The *request method name* for any request method except *GET* or *HEAD* or if the request extension is empty.
+
+The *resource type* is used as a (relative) parent path to the Servlet while the *request extension* or *request method* is used as the Servlet (base) name. The Servlet is retrieved from the Resource tree by calling the `ResourceResolver.getResource(String)` method which handles absolute and relative paths correctly by searching realtive paths in the configured search path.
+
+The pseudo-code for Servlet resolution is as follows:
+
+
+    Servlet resolveServlet(SlingHttpServletRequest request) {
+    
+        String resourceType = request.getResource().getResourceType();
+        resourceType = resourceType.replaceAll("\\:", "/");
+    
+        String baseName;
+        if (("GET".equals(request.getMethod()) || "HEAD".equals(request.getMethod())
+                && request.getRequestPathInfo().getExtension() != null) {
+            baseName = request.getRequestPathInfo().getExtension();
+        } else {
+            baseName = request.getMethod();
+        }
+    
+        if (request.getRequestPath().getSelectorString() != null) {
+            String selectors = request.getRequestPath().getSelectorString();
+            selectors = selectors.replace('.', '/');
+            while (selectors != null) {
+                String path = resourceType + "/" + selectors + "/" + baseName;
+                Servlet servlet = findServletFor(path);
+                if (servlet != null) {
+                    return servlet;
+                }
+    
+                int lastSlash = selectors.lastIndexOf('/');
+                if (lastSlash > 0) {
+                    selectors = selectors.substring(0, lastSlash);
+                } else {
+                    selectors = null;
+                }
+            }
+        }
+            
+        String path = resourceType + "/" + baseName;
+        return findScriptFor(path);
+    }
+    
+    Servlet findScriptFor(path) {
+        // Find a Servlet or Script with the given path in the search path
+        // where the Script is allowed to have Script language specific
+        // extension, such as .js, .jsp, etc.
+    }
+
+
+
+## Default Servlet(s)
+
+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 `sling/servlet/default`.
+
+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.
+
+Finally, if not even a registered default Servlet may be resolved for the request, because none has been registered, the `sling/servlet-resolve` bundle provides a fall back `DefaultServlet` with the following functionality:
+
+   * If the request has no extension and the Resource of the request adapts to an `InputStream`, the contents of the resoure is stream out as the response. The response content type is taken from the `sling.contentType` Resource meta data or derived from the Resource path. If the `sling.characterEncoding` 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.
+   * Otherwise if the object has an OCM mapping, the properties of the mapped object are printed.
+   * Otherwise just the path of the Resource is printed.
+
+
+## Error Handler Servlet(s)
+
+The `sling/servlet-resolver` project also provides an implementation of the Sling Core `ErrorHandler` 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 `sling/servlet/errorhandler` and an error specific name:
+
+   * *HTTP Status Code Handling*: To handle HTTP status code as used by the `HttpServletResponse.sendError` 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 `prefix/sling/servlet/errorhandler/404.esp` or for a status code 500 (INTERNAL*SERVER_ERRROR), you might want to register a Servlet at `prefix/sling/servlet/errorhandler/500`.
+   * *Throwable Handling*: To handle uncaught `Throwables` the simple name of the `Throwable` class is used as the Servlet name. 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.
+
+## Integration tests
+A set of simple example servlets is available in the [launchpad/test-services module]({{ refs.http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/test-services.path }}). 
+
+Integration tests in the [launchpad/testing module]({{ refs.http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution.path }}) verify that these examples are correct.
+
+Contributions to these tests and examples are welcome, of course!

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/old-stuff/sling-api.md
----------------------------------------------------------------------
diff --git a/content/old-stuff/sling-api.md b/content/old-stuff/sling-api.md
new file mode 100644
index 0000000..c8946f3
--- /dev/null
+++ b/content/old-stuff/sling-api.md
@@ -0,0 +1,245 @@
+title=Sling API
+type=page
+status=published
+~~~~~~
+
+<div class="note">
+The contents of this page is being created at the moment. It contains incomplete and partially wrong information as the text is adapted from the contents of the [Component API]({{ refs.component-api.path }}) documentation page.
+</div>
+
+
+## Introduction
+
+The *Sling API* defines a presentation framework to build Web Applications. As such the Sling API builds upon the Servlet API but extends the latter with new functionality:
+
+* A web page may be built from many different pieces. This aggregation of different pieces is comparable to the functionality provided by the Portlet API. In contrast to the latter, though, the pieces may themselves be aggregates of yet more pieces. So a single web page response may consist of a tree of pieces.
+* Just like the Servlet API and the Portlet API the Sling API mainly defines a Java based framework. Yet the Sling API comes with the intention of supporting scripting built.
+* In contrast to the Servlet API and the Portlet API, the Sling API is resource centric. That is, the request URL does not address a servlet or a portlet but a resource represented by an instance of the `org.apache.sling.api.resource.Resource` interface. From this resource the implementation of the Sling API will derive a `javax.servlet.Servlet` or `org.apache.sling.api.scripting.SlingScript` instance, which is used to handle the request.
+
+An implementation of the presentation framework defined by the Sling API is called a *Sling Framework*. The Apache Sling project actually contains two implementations of this API: *microsling* and *Sling*. microsling (note the lowercase *m*) implements the same request processing mechanisms as *Sling* but is very hardcoded. It serves well as a rapid development environment as it is quickly set up, easy to handle and shows results very easily. Sling on the other hand is based on an OSGi framework and very flexible, allowing the extension of the system in various ways.
+
+
+
+## Going Resource Centric
+
+Traditional web applications are built around the notion of a traditional application which is converted into an application which may be used using a Web Browser. Web applications consist of a series of servlets and JSP scripts, which are called based on configuration in the web application deployment descriptor. Such applications are generally based on some internal database or some static filesystem content.
+
+The Sling API on the other hand looks more like a traditional web server from the outside, which delivers more or less static content. Thus, while the traditional web application uses the request URL to select a piece of code to execute, the Sling API uses the URL to select a resource to be delivered.
+
+
+
+### Comparsion to the Servlet API
+
+The Sling API builds upon the Servlet API. Generally a Sling Framework will run inside a Servlet Container and be manifested towards the Servlet Container as a single Servlet, which dispatches requests to the Servlets and Scripts depending on the request URLs.
+
+Response rendering may itself be a multi-step operation. Depending on the Servlets and Scripts, the rendering may include dispatching for child (or even foreign) Resources.
+
+
+
+### Comparision to the Portlet API
+
+Unlike the Portlet API, which defines one single level of portlet hierarchy - portlets are just pieces residing besides each other - the Sling API allows for hierarchic structuring of Resources and hence Servlet and Script renderings. To support this structuring, the Sling Framework does not control the rendering process of all elements on the page like the Portlet Container does for the portlets. Instead only the Resource addressed by the request URL is processed and it is left to the Servlet or Script rendering that Resource to dispatch other Resource/Servlet/Script tupels to add more data to the response.
+
+
+### To Iterator or To Enumeration
+
+With the advent of the Java Collection framework in Java 2, the `Enumeration` has been superceded by the `Iterator`. So the natural choice for the Sling API for methods to return enumeratable collection of objects would have be to declare the use of `Iterator` instances. But because the Servlet API defines to use `Enumeration` instances, the Sling API will also declare the use of `Enumeration` instances for consistency with the Servlet API extended by the Sling API.
+
+
+
+
+## Request Processing
+
+Unlike traditional Servlet API request processing, a Sling API request is processed by the Sling Framework in three basic steps:
+
+1. *Resource Resolution* - The Sling Framework derives a Resource instance from the client request URL. The details of how to resolve the Resource. One possible solution would be to map the request URL to a [Java Content Repository]({{ refs.http://www.jcp.org/en/jsr/detail?id=170.path }}) Node and return a Resource representing that Node.
+1. *Servlet and Script Resolution* - From the Resource created in the first step, the Servlet or Script is resolved based on the type of the Resource. The resource type is a simple string, whose semantics is defined by the Sling Framework. One possible definition could be for the resource type to be the primary node type of the Node underlying the Resource.
+1. *Input Processing and Response Generation* -  After getting the Resource and the Servlet or Script, the `service()` method is called or the script is evaluated to process any user supplied input and send the response to the client. To structure the rendered response page, this method is responsible to include other resources. See *Dispatching Requests* below for details. See *Error Handling* below for a discussion on how exceptions and HTTP stati are handled.
+
+
+
+### URL decomposition
+
+During the *Resource Resolution* step, the client request URL is decomposed into the following parts:
+
+1. *Resource Path* -  The longest substring of the request URL resolving to a Resource such that the resource path is either the complete request URL or the next character in the request URL after the resource path is either a dot (`.`) or a slash (`/`).
+1. *Selectors* -  If the first character in the request URL after the resource path is a dot, the string after the dot upto but not including the last dot before the next slash character or the end of the request URL. If the resource path spans the complete request URL or if a slash follows the resource path in the request URL, no seletors exist. If only one dot follows the resource path before the end of the request URL or the next slash, no selectors exist.
+1. *Extension* -  The string after the last dot after the resource path in the request URL but before the end of the request URL or the next slash after the resource path in the request URL. If a slash follows the resource path in the request URL, the extension is empty.
+1. *Suffix Path* -  If the request URL contains a slash character after the resource path and optional selectors and extension, the path starting with the slash upto the end of the request URL is the suffix path. Otherwise, the suffix path is empty.
+
+*Examples*: Assume there is a Resource at `/a/b`, which has no children.
+
+| URI | Resource Path | Selectors | Extension | Suffix |
+|--|--|--|--|--|
+| /a/b                      | /a/b | null  | null | null       |
+| /a/b.html                 | /a/b | null  | html | null       |
+| /a/b.s1.html              | /a/b | s1    | html | null       |
+| /a/b.s1.s2.html           | /a/b | s1.s2 | html | null       |
+| /a/b/c/d                  | /a/b | null  | null | /c/d       |
+| /a/b.html/c/d             | /a/b | null  | html | /c/d       |
+| /a/b.s1.html/c/d          | /a/b | s1    | html | /c/d       |
+| /a/b.s1.s2.html/c/d       | /a/b | s1.s2 | html | /c/d       |
+| /a/b/c/d.s.txt            | /a/b | null  | null | /c/d.s.txt |
+| /a/b.html/c/d.s.txt       | /a/b | null  | html | /c/d.s.txt |
+| /a/b.s1.html/c/d.s.txt    | /a/b | s1    | html | /c/d.s.txt |
+| /a/b.s1.s2.html/c/d.s.txt | /a/b | s1.s2 | html | /c/d.s.txt |
+
+<div class="info">
+The [SlingRequestPathInfoTest]({{ refs.http://svn.apache.org/repos/asf/sling/trunk/bundles/engine/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java.path }}) demonstrates and tests this decomposition. Feel free to suggest additional tests that help clarify how this works!
+</div>
+
+## The SlingHttpServletRequest
+
+The `org.apache.sling.api.SlingHttpServletRequest` interface defines the basic data available from the client request to both action processing and response rendering. The `SlingHttpServletRequest` extends the `javax.servlet.http.HTTPServletRequest`.
+
+This section describes the data available from the `SlingHttpServletRequest`. For a complete and normative description of the methods, refer to the Sling API JavaDoc. The following information is represented for reference. In the case of differences between the following descriptions and the Sling API JavaDoc, the latter takes precedence.
+
+1. *Resource access* - Resources may be accessed from the `SlingHttpServletRequest` object through the following methods: `getResource()`, `getResourceResolver()`.
+1. *Request URL information* - In addition to the standard `HttpServletRequest` information the `SlingHttpServletRequest` provides access to the selectors, extension and suffix through the `getRequestPathInfo()` method. Note that the Resource path is not directly available form the `SlingHttpServletRequest` object. Instead it is available through the `Resource.getPath()` method of the Resource object retrieved through `SlingHttpServletRequest.getResource()`.
+1. *Request Parameters* - To support user input submitted as `multipart/form-data` encoded POST parameters, the Sling API intrduces the `RequestParameter` interface allowing file uploads. Request parameters represented as `RequestParameter` objects are returned by the following methods: `getRequestParameter(String name)`, `getRequestParameterMap()`, `getRequestParameters(String name)`.
+1. *Request Dispatching* - In addition to standard Serlvet API request dispatching, the Sling API supports dispatching requests to render different Resources using `RequestDispatcher` objects returned by the methods: `getRequestDispatcher(Resource resource)` and `getRequestDispatcher(Resource resource, RequestDispatcherOptions options)`.
+1. *Miscellaneous* - Finally the ComponentRequest interface provides the following methods: `getCookie(String name)`, `getRequestProgressTracker()`, `getResponseContentType()`, `getResponseContentTypes()`, `getResourceBundle(Locale locale)`, `getServiceLocator()`.
+
+The `SlingHttpServletRequest` objects are only valid during the time of request processing. Servlets and Scripts must not keep references for later use. As such, the `SlingHttpServletRequest` interface and its extensions are defined to not be thread safe.
+
+*A note on HTTP Sessions*: The `SlingHttpServletRequest` extends the `HttpSerlvetRequest` and thus supports standard HTTP sessions. Be aware, though that Sessions are server side sessions and hence violate the sessionless principle of REST and therefore should be used with care. It is almost always possible to not use sessions.
+
+
+## The SlingHttpServletResponse
+
+The `org.apache.sling.api.SlingHttpServletResponse` interface extends the `javax.servet.http.HttpServletResponse` interface and is currently empty. It merely exists for symmetry with the `SlingHttpServletRequest`.
+
+
+
+
+## The Resource
+
+The `org.apache.sling.resource.Resource` represents the data addressed by the request URL. Resources may also be retrieved through the `org.apache.sling.api.resource.ResourceResolver`. Usually this interface is not implemented by clients. In certain use cases we call *synthetic Resource* if may be usefull to define a simple object implementing the `Resource` interface. The Sling Framework does not care about the concrete implementation of the `Resource` interface and rather uses the defined methods to access required information. The interface defines the following methods:
+
+1. *getResourceType()* - Returns the type of the resource. This resource type is used to resolve the Servlet or Script used to handle the request for the resource.
+1. *getPath()* - Returns the path derived from the client request URL which led to the creation of the Resource instance. See the [#URL_decomposition URL decomposition]({{ refs.-url_decomposition-url-decomposition.path }}) section above for more information. It is not required, that the Resource path be a part of the original client request URL. The request URL may also have been mapped to some internal path.
+1. *getResourceMetadata()* - Returns meta data information about the resource in a `ResourceMetadata` object.
+1. *adaptTo(Class<AdapterType> type)* - Returns alternative representations of the Resource. The concrete supported classes to which the Resource may be adapted depends on the implementation. For example a Resource based on a JCR Node may support being adapted to the underlying Node, an `InputStream`, an `URL` or even to a mapped object through JCR Object Content Mapping.
+
+----
+
+
+
+## The Component
+
+The `org.apache.sling.component.Component` interface defines the API implemented to actually handle requests. As such the Component interface is comparable to the =javax.servlet.Servlet= interface. Like those other interfaces, the Component interface provides methods for life cycle management: `init(ComponentContext context)`, `destroy()`.
+
+
+
+### Processing the Request
+
+The Component Framework calls the `service(ComponentRequest request, ComponentResponse response)` method of the Component to have the component process the request optionally processing user input, rendering the response and optionally dispatch to other Content/Component tuples to provide more response data.
+
+
+
+### Content and its Component
+
+The Content object and a Component form a pair, in which the Content object takes the passive part of providing data to the Component and the Component takes the active part of acting upon the Content object. As a consequence, there always exists a link between a given implementation of the Content interface and a given implementation of the Component interface.
+
+This link is manifested by the Component identifier available from the Content object through the `Content.getComponentId()` method on the one hand. On the other hand, the link is manifested by the `getContentClassName()` and `createContentInstance()` methods of the Component interface.
+
+
+
+### Component Lifecylce
+
+When a Component instance is created and added to the Component framework, the `init(ComponentContext)` method is called to prepare and initialize the Component. If this method terminates abnormally by throwing an exception, the Component is not used. The Component Framework implementation may try at a later time to recreate the Component, intialize it and use it. If the Component Framework tries to recreate the Component a new instance of the Component must be created to be initialized and used.
+
+When the Component has successfully been initialized, it may be referred to by Content objects. When a client request is to be processed, the Content object is resolved and the `service` method on the Component to which the Content object refers is called. The `service` method may - and generally will - be called simultaneously to handle different requests in different threads. As such, implementations of these methods must be thread safe.
+
+When the Component Framework decides to take a Component out of service, the `destroy()` method is called to give the Component a chance to cleanup any held resources. The destroy method must only be called by the Component Framework when no more request processing is using the Component, that is no thread may be in the `service` method of a Component to be destroyed. Irrespective of whether the destroy method terminated normally or abnormally, the Component will not be used again.
+
+The addition and removal of Components is at the discretion of the Component Framework. A Component may be loaded at framework start time or on demand and my be removed at any time. But only one single Component instance with the same Component identifier may be active at the same time within a single Component Framework instance.
+
+
+
+### The ComponentExtension
+
+To enhance the core functionality of Components, each Component may have zero, one ore more Component Extensions attached. A Component Extensions is a Java object implementing the `org.apache.sling.component.ComponentExtension` interface. This interface just defines a `getName()` method to identify extensions.
+
+The concrete implementation as well as instantiation and management of Component Extensions is left to the Component Framework implementation with one restriction though: The extensions must be available to the Component at the time the `init(ComponentContext)` method is called may only be dropped after the `destroy()` method terminates.
+
+The Component interface defines two methods to access Extensions: The `getExtensions()` method returns a `java.util.Enumeration` of all ComponentExtension objects attached to the component. If no Component Extension are attached to the Component, an empty enumeration is returned. The `getExtension(String name)` returns the named Component Extension attached to the Component or `null` if no such Component Extension is attached to the Component.
+
+Component Frameworks are allowed to share Component Extension instances of the same name between different Component instances. Regardless of whether Component Extensions are shared or not, they must be thread safe, as any Component Extension may be used within the `service` method, which themselves may be called concurrently.
+
+
+
+
+## Request Processing Filters
+
+Similar to the Servlet API providing filters for filtering requests and/or responses the Component API provides the `org.apache.sling.component.ComponentFilter` interface. The filters are called by a `ComponentFilterChain` and either handle the request, manipulate the request and/or response object and finally forward the request and response optionally wrapped to the `ComponentFilterChain.doFilter(ComponentRequest, ComponentResponse)` method.
+
+Like the `Component`s  filters have a defined lifecycle manifested by `init` and `destroy` methods. When the filter enters the system, the Component Framework calls the `ComponentFilter.init(ComponentContext)` method. Only when this method completes successfully will the filter be put into action and be used during request processing. When the filter leaves the system, the Component Framework removes the filter from being used in filter chains and calls the `ComponentFilter.destroy()` method. This method is not expected to throw any exceptions. The filter may be removed from the Component Framework at the discretion of the Component Framework or because the filter is being unregistered from the Component Framework by some means outside this specification.
+
+This specification does not define how `ComponentFilter` objects are registered with the Component Framework nor is it specified how the order in which the filters are called is defined. Likewise it is outside this specification how the filter instances registered with the Component Framework are configured.
+
+
+
+## Sessions
+
+
+The `org.apache.sling.component.ComponentSession` interface provides a way to identify a user across more than one request and to store transient information about that user.
+
+A component can bind an object attribute into a `ComponentSession` by name. The `ComponentSession` interface defines two scopes for storing objects: `APPLICATION*SCOPE`, `COMPONENT*SCOPE`. All objects stored in the session using the `APPLICATION*SCOPE` must be available to all the components, servlets and JSPs that belong to the same component application and that handle a request identified as being a part of the same session. Objects stored in the session using the `COMPONENT*SCOPE` must be available to the component during requests for the same content that the objects where stored from. Attributes stored in the `COMPONENT_SCOPE` are not protected from other web components of the component application. They are just conveniently namespaced.
+
+The component session extends the Servlet API `HttpSession`. Therefore all `HttpSession` listeners do apply to the component session and attributes set in the component session are visible in the `HttpSession` and vice versa.
+
+The attribute accessor methods without the *scope* parameter always refer to `COMPONENT*SCOPE` attributes. To access `APPLICATION*SCOPE` attributes use the accessors taking an explicit `scope` parameter.
+
+*A final note on Sessions*: Sessions are server side sessions and hence violate the sessionless principle of REST and therefore should be used with care. It is almost always possible to not use sessions.
+
+
+
+## Dispatching Requests
+
+To include renderings of child Content objects, a `org.apache.sling.component.ComponentRequestDispatcher` object may be retrieved from the ComponentContext with which the Component has been initialized or from the ComponentRequest provided to the service method. Using this dispatcher the reponse of rendering the Content may be included by calling the `ComponentRequestDispatcher.include(ComponentRequest, ComponentResponse)` method.
+
+This method is comparable to the `RequestDispatcher.include(ServletRequest, ServletResponse` method of the Servlet API but dispatching by the `ComponentRequestDispatcher` does not go through the servlet container and stays within the Component Framework.
+
+The `service` method of included Components are called with an instance of the `ComponentRequest` interface whose `getContent()` returns the Content object for the included Content.
+
+When a Component is included by another component the following request attributes are set:
+
+| *Request Attributes* | *Type* | *Description* |
+|--|--|--|
+| `org.apache.sling.component.request.content` | String | The `Content` instance to which the client URL resolved. This attribute is set when included Components are being rendered and it is not set for the Component directly addressed by the client request. |
+| `org.apache.sling.component.request.component` | String | The `Component` instance for the `Content` object to which the client URL resolved. This attribute is set when included Components are being rendered and it is not set for the Component directly addressed by the client request. |
+
+
+### Error Handling
+
+While processing requests, the `service` methods called may have problems. Components have multiple options of reporting issues during processing to the client:
+
+* Set the status of the HTTP response calling the `ComponentResponse.setStatus` method
+* Send an error page calling the `ComponentResponse.sendError` method
+* Throw an exception
+
+
+If such an exception is thrown, the Component Framework must act upon the exception in one of the following ways:
+
+* If the request is processed through Servlet API request inclusion, the exception must be given back to the servlet container. A `ComponentException` is just forwarded as a `ServletException`. This is a requirement of the Servlet API specification which states for included requests:
+
+{quote}
+  
+  
+{quote}
+
+* Otherwise, the Component Framework may handle the error itself in a manner similar to the error handling approach defined the Servlet API specification (Section SRV 9.9 Error Handling of the Java Servlet Specification 2.4). Specifically the request attributes defined by the Servlet API specification must be set for the error handler:
+
+| *Request Attributes* | *Type* | *Description* |
+|--|--|--|
+| `javax.servlet.error.status_code` | `java.lang.Integer` | The status code of the response. In the case of an exception thrown from the `service`, the code is defined by the Component Framework. |
+| `javax.servlet.error.exception_type` | `java.lang.Class` | The fully qualified name of the exception class thrown. This attribute does not exist, if error handling does not result from an exception. This attribute is maintained for backwards compatibility according to the Servlet API Specification. |
+| `javax.servlet.error.message` | `java.lang.String` | The message of the exception thrown. This attribute does not exist, if error handling does not result from an exception. This attribute is maintained for backwards compatibility according to the Servlet API Specification. |
+| `javax.servlet.error.exception` | `java.lang.Throwable` | The exception thrown. This attribute does not exist, if error handling does not result from an exception. |
+| `javax.servlet.error.request_uri` | `java.lang.String` | The request URL whose processing resulted in the error. |
+| `javax.servlet.error.servlet_name` | `java.lang.String` | The name of the servlet which yielded the error. The servlet name will generally not have any significance inside the Component Framework. |
+| `org.apache.sling.component.error.componentId` | `java.lang.String` | The identifier of the Component whose `service` method has caused the error. This attribute does not exist, if the Component Framework itself caused the error processing. |
+* If the Component Framework decides to not handle the error itself, the exception must be forwarded to the servlet container as a `ComponentException` wrapping the original exception as its root cause.
+
+This specification does not define, how error handlers are configured and used if the Component Framework provides error handling support. Likewise the Component Framework may or may not implement support to handle calls to the `ComponentResponse.sendError` method. The Component Framework may also use its own error handling also for errors resulting from request processing failures, for example if authentication is required or if the request URL cannot be resolved to a Content object.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/2d8c7ce5/content/plugins.md
----------------------------------------------------------------------
diff --git a/content/plugins.md b/content/plugins.md
deleted file mode 100644
index 4a26182..0000000
--- a/content/plugins.md
+++ /dev/null
@@ -1,10 +0,0 @@
-title=Plugins		
-type=page
-status=published
-~~~~~~
-translation_pending: true
-
-These pages present the various Maven Plugins of Sling:
-
-{% for label, page in children %}* [{{ page.headers.title }}]({{ page.path }})
-{% endfor %}


Mime
View raw message