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:31:11 UTC
[27/50] [abbrv] sling-site git commit: Fix front matter,
using existing titles
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/development/slingstart.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/slingstart.md b/content/documentation/development/slingstart.md
index ff62e85..88cd698 100644
--- a/content/documentation/development/slingstart.md
+++ b/content/documentation/development/slingstart.md
@@ -1,10 +1,7 @@
-title=TODO title for slingstart.md
-date=1900-01-01
-type=post
-tags=blog
+title=The Apache Sling Provisioning Model and Apache SlingStart
+type=page
status=published
~~~~~~
-Title: The Apache Sling Provisioning Model and Apache SlingStart
[TOC]
@@ -19,14 +16,14 @@ For Apache Maven users, the `slingstart-maven-plugin` uses the model to create a
The model is a simple API consisting of data objects:
- * Model: This is the central object. It consists of features.
- * Feature : this is the central object describing a (partial) system. A feature consists of variables and run modes.
- * Variables: These can be used to define artifact versions, settings values or configuration property values.
- * Run Mode : A run mode contains artifacts, configurations, and settings. The artifacts are divided into artifact groups.
- * Artifact Group: A group of artifacts with an associated start level (the artifacts are usually bundles)
- * Artifact: A deployable artifact described by Maven coordinates.
- * Configuration: A OSGi configuration
- * Settings : Framework settings for the OSGi framework
+* Model: This is the central object. It consists of features.
+* Feature : this is the central object describing a (partial) system. A feature consists of variables and run modes.
+* Variables: These can be used to define artifact versions, settings values or configuration property values.
+* Run Mode : A run mode contains artifacts, configurations, and settings. The artifacts are divided into artifact groups.
+* Artifact Group: A group of artifacts with an associated start level (the artifacts are usually bundles)
+* Artifact: A deployable artifact described by Maven coordinates.
+* Configuration: A OSGi configuration
+* Settings : Framework settings for the OSGi framework
### Run Modes
@@ -35,10 +32,10 @@ Custom run modes can be used to configure for different situations. Depending on
Each run mode is associated with a set of run mode names. Only if all listed run modes are active, the definition is used.
The model also supports special run modes, which have special meaning. By default, these pre defined special run modes are available:
-
- * :standalone Artifacts for the standalone application - in contrast to a war.
- * :webapp Artifacts for the webapp only
-
+
+* :standalone Artifacts for the standalone application - in contrast to a war.
+* :webapp Artifacts for the webapp only
+
Other special run modes can be defined by using a single run mode name which starts with a colon, like :test. These run modes can be used by special tooling.
### Start Levels
@@ -49,18 +46,18 @@ Each run mode has start levels. These start levels correspond to OSGi start leve
An artifact is defined by Maven coordinates, that is group id, artifact id and version. Type and classifier can be specified, too. Type defaults to "jar". Although the maven way of referring to an artifact is used, the model is in no way tied to Maven and can be used with any tooling. For a plain jar the text definition for an artifact is:
- groupId/artifactId/version
- org.apache.sling/api/2.8.0
+groupId/artifactId/version
+org.apache.sling/api/2.8.0
If you want to specify the type, it's appended after the version:
- groupId/artifactId/version/type
- org.apache.sling/api/2.8.0/jar
-
+groupId/artifactId/version/type
+org.apache.sling/api/2.8.0/jar
+
If you want to specify the classifier, it gets appended after the type:
-
- groupId/artifactId/version/type/classifier
- org.apache.sling/api/2.8.0/jar/test
+
+groupId/artifactId/version/type/classifier
+org.apache.sling/api/2.8.0/jar/test
### Configurations
@@ -68,22 +65,22 @@ A configuration has a pid, or a factory pid and an alias and of course the prope
Special configurations can be marked with a leading ":" of the pid. Special configurations are not added to the OSGi config admin. There are some predefined special configurations
- * :web.xml This configuration must be part of the :webapp runmode and contains a complete web.xml for the web application
- * :bootstrap This configuration must be part of either the :boot, :base, :standalone, or :webapp run mode and define the contents for the bootstrap command file executed by Launchpad.
+* :web.xml This configuration must be part of the :webapp runmode and contains a complete web.xml for the web application
+* :bootstrap This configuration must be part of either the :boot, :base, :standalone, or :webapp run mode and define the contents for the bootstrap command file executed by Launchpad.
#### Bootstrap Command File
The bootstrap configuration is a text block consisting of uninstall directives. This block is only executed on the first startup.
- [feature name=:launchpad]
+[feature name=:launchpad]
- [configurations]
- # uninstall obsolete bundles which are neither not required anymore or are
- # replaced with new bundles
- :bootstrap
- uninstall org.apache.sling.fragment.activation 1.2
- uninstall org.apache.sling.installer.api [1.0,2.0)
- uninstall org.apache.sling.tests
+[configurations]
+# uninstall obsolete bundles which are neither not required anymore or are
+# replaced with new bundles
+:bootstrap
+uninstall org.apache.sling.fragment.activation 1.2
+uninstall org.apache.sling.installer.api [1.0,2.0)
+uninstall org.apache.sling.tests
Each uninstall directive starts with the text "uninstall" followed by the bundle symbolic name. A version range can be specified as well. If no version information is specified, the bundle with that symbolic name is uninstalled on startup. If a version is specified, the bundle is only uninstalled if it's installed with the exact same version. If a range is specified, the bundle is only uninstalled, if the version is within that range.
@@ -95,65 +92,65 @@ Settings are key value pairs that are added to the framework properties. For now
Features group run modes and define a special functionality. The model also defines two special features:
- * :launchpad This feature contains the dependency to Sling's launchpad artifact to be used. This mode is required if Apache Sling Launchpad should be used to start the application.
- * :boot The artifacts that are installed before the framework is started. They're used to bootstrap the system.
+* :launchpad This feature contains the dependency to Sling's launchpad artifact to be used. This mode is required if Apache Sling Launchpad should be used to start the application.
+* :boot The artifacts that are installed before the framework is started. They're used to bootstrap the system.
## Model Files
The model comes also with a textual description language:
- [feature name=my-feature]
- [variables]
- eventadmin.version=1.0.0
- metatype.version=1.2.0
-
- [artifacts]
- org.apache.sling/eventadmin/${eventadmin.version}
- org.apache.sling/metatype/${metatype.version}
- org.apache.sling/coordinator/3.0.0
-
- [configurations]
- org.apache.sling.eventadmin
- useQueue=true
- ignoreTopics=["myTopic"]
+[feature name=my-feature]
+[variables]
+eventadmin.version=1.0.0
+metatype.version=1.2.0
+
+[artifacts]
+org.apache.sling/eventadmin/${eventadmin.version}
+org.apache.sling/metatype/${metatype.version}
+org.apache.sling/coordinator/3.0.0
+
+[configurations]
+org.apache.sling.eventadmin
+useQueue=true
+ignoreTopics=["myTopic"]
A configuration for a run mode looks like this:
- [feature name=my-feature]
- [variables]
- eventadmin.version=1.0.0
- metatype.version=1.2.0
-
- [artifacts runModes=mymode]
- org.apache.sling/metatype/${metatype.version}
-
- [artifacts startLevel=5 runModes=mymode]
- org.apache.sling/eventadmin/${eventadmin.version}
-
- [configurations runModes=mymode]
- org.apache.sling.eventadmin
- useQueue=true
- ignoreTopics=["myTopic"]
+[feature name=my-feature]
+[variables]
+eventadmin.version=1.0.0
+metatype.version=1.2.0
+
+[artifacts runModes=mymode]
+org.apache.sling/metatype/${metatype.version}
+
+[artifacts startLevel=5 runModes=mymode]
+org.apache.sling/eventadmin/${eventadmin.version}
+
+[configurations runModes=mymode]
+org.apache.sling.eventadmin
+useQueue=true
+ignoreTopics=["myTopic"]
### Comments
Each object in the model can be annotated with comments. A comment is a line starting with a '#'. Leading spaces are ignored.
### Configurations in the Model file
-
+
Configuration names are related to the PID and factory PID. The structure of the name is as follows:
-
- name ::= <pid> ( '-' <subname> )
-
+name ::= <pid> ( '-' <subname> )
+
+
If the form is just `<pid>`, the configuration contains the properties for a Managed Service. The `<pid>` is then the PID of the Managed Service. See the Configuration Admin service for details.
-
+
When a Managed Service Factory is used, the situation is different. The `<pid>` part then describes the PID of the Managed Service Factory. You can pick any `<subname>` which is used as a unique alias. For example:
-
- # Configuration for Managed Service com.acme.xyz
- com.acme.xyz //
- # Managed Service Factory, creates an instance for com.acme.abc
- com.acme.abc-default
+
+# Configuration for Managed Service com.acme.xyz
+com.acme.xyz //
+# Managed Service Factory, creates an instance for com.acme.abc
+com.acme.abc-default
### Default Configuration Format
@@ -164,17 +161,17 @@ The first line of such a file might start with a comment line (a line starting w
The format is:
- file ::= (comment) (header) *
- comment ::= '#' <any>
- header ::= prop '=' value
- prop ::= symbolic-name // 1.4.2 of OSGi Core Specification
- symbolic-name ::= token { '.' token }
- token ::= { [ 0..9 ] | [ a..z ] | [ A..Z ] | '_' | '-' }
- value ::= [ type ] ( '[' values ']' | '(' values ')' | simple )
- values ::= simple { ',' simple }
- simple ::= '"' stringsimple '"'
- type ::= <1-char type code>
- stringsimple ::= <quoted string representation of the value> (see below)
+file ::= (comment) (header) *
+comment ::= '#' <any>
+header ::= prop '=' value
+prop ::= symbolic-name // 1.4.2 of OSGi Core Specification
+symbolic-name ::= token { '.' token }
+token ::= { [ 0..9 ] | [ a..z ] | [ A..Z ] | '_' | '-' }
+value ::= [ type ] ( '[' values ']' | '(' values ')' | simple )
+values ::= simple { ',' simple }
+simple ::= '"' stringsimple '"'
+type ::= <1-char type code>
+stringsimple ::= <quoted string representation of the value> (see below)
The 1 character type code is one of:
@@ -195,9 +192,9 @@ Apart from the escaping of the usual characters like the quotes, double quotes,
While the default configuration form is very powerful, it might also sometimes be a little bit too heavy to specify a configuration. For these usage cases, the configuration can be described as properties:
- com.acme.xyz [format=properties]
- ftp.port = 21
-
+com.acme.xyz [format=properties]
+ftp.port = 21
+
Notice that this definition only supports string properties. Therefore the service consuming the configuration needs to be able to adapt a string value to the correct type.
## Slingstart and Slingfeature projects
@@ -209,9 +206,9 @@ The `slingstart-maven-plugin` introduces two new packaging types:
A model can reference other slingstart or slingfeature artifacts. When such an artifact is reference, the type needs to be specified, for example:
- [artifacts]
- org.apache.sling/org.apache.sling.launchpad/8-SNAPSHOT/slingstart
- org.apache.sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/slingfeature
+[artifacts]
+org.apache.sling/org.apache.sling.launchpad/8-SNAPSHOT/slingstart
+org.apache.sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/slingfeature
The resulting model is a merged model, starting with the dependencies and then merging in the current model.
@@ -219,9 +216,9 @@ By default the Maven classpath is extended by the dependencies of the merged mod
## Model Merging
-If two or more models are supplied, they are merged feature by feature, each feature being treated as a separate unit.
+If two or more models are supplied, they are merged feature by feature, each feature being treated as a separate unit.
-Within a feature each run mode is treated separately as well.
+Within a feature each run mode is treated separately as well.
Within a run mode, a model can overwrite definitions from the base model. For example, it can define a different configuration or a different version and/or start level for an artifact.
@@ -233,12 +230,12 @@ In addition, it can also remove artifacts and configurations. For this the speci
Let's look at an example base model
- [artifacts]
- my/special/artifact/1.0.0
- commons/library/1.0.0
-
- [artifacts runModes=test]
- another/one/2.1.0
+[artifacts]
+my/special/artifact/1.0.0
+commons/library/1.0.0
+
+[artifacts runModes=test]
+another/one/2.1.0
Another model wants to use the above model as it's base but:
@@ -247,14 +244,14 @@ Another model wants to use the above model as it's base but:
* Remove the "another one"
The changing model would mention the above as one artifact and in addition have:
- [artifacts startLevel=5]
- commons/library/1.1.0
-
- [artifacts runModes=:remove]
- my/special/artifact/0.0.0
-
- [artifacts runModes=:remove,test]
- another/one/0.0.0
+[artifacts startLevel=5]
+commons/library/1.1.0
+
+[artifacts runModes=:remove]
+my/special/artifact/0.0.0
+
+[artifacts runModes=:remove,test]
+another/one/0.0.0
Note that the version for removal does not play a role, it's not compared for an exact match. But please keep in mind that the remove directive needs to be specified in the same feature and run mode as the original.
@@ -262,28 +259,28 @@ Note that the version for removal does not play a role, it's not compared for an
Configurations can be removed in the same way by just specifying their PID in the :remove run mode. This is the base model:
- [configurations]
- my.special.configuration.b
- foo="bar"
- another.special.configuration.a
- x="y"
+[configurations]
+my.special.configuration.b
+foo="bar"
+another.special.configuration.a
+x="y"
When this model is merged with the following model, the resulting model has a different configuration for my.special.configuration.b and no configuration for another.special.configuration.a:
- [configurations]
- my.special.configuration.b
- a="b"
+[configurations]
+my.special.configuration.b
+a="b"
- [configurations runModes=:remove]
- another.special.configuration.a
+[configurations runModes=:remove]
+another.special.configuration.a
-By default if a model inherits from another and uses the same configuration pid, the configuration is overwritten! In the above example, the configuration my.special.configuration.b contains a single property named "a".
+By default if a model inherits from another and uses the same configuration pid, the configuration is overwritten! In the above example, the configuration my.special.configuration.b contains a single property named "a".
It is also possible to merge configurations:
- [configurations]
- my.special.configuration.b [mode=merge]
- a="b"
+[configurations]
+my.special.configuration.b [mode=merge]
+a="b"
When the merge directive is used, the configurations are merged and the properties are applied as a delta to the base configuration. Therefore the configuration my.special.configuration.b will have two properties "a" and "foo".
@@ -319,7 +316,7 @@ stdOutFile | String | The relative filename of the file which receives both the
Since version 1.2.0 of this plugin it is possible to easily start a Sling server in debug mode ([SLING-4677](https://issues.apache.org/jira/browse/SLING-4677)). For that you either configure the property `debug` inside you server configuration in the pom.xml accordingly or by using the parameter `Dlaunchpad.debug`. Both values can either be `true` (in which case the [JDWP options](http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html#Invocation) `-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000` are appended to the VM options) or just some arbitrary string defining debugging options.
In case both are used the parameter `Dlaunchpad.debug` takes precedence.
-## Stopping a server
+## Stopping a server
Use the goal with name `stop` to stop one or multiple servers. The goal is bound by default to the [`post-integration-test` lifecycle phase](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference).
@@ -333,17 +330,17 @@ Starting with version 1.2.0 of the provisioning model and version 1.2.0 of the s
If you want to stick with the old format from config admin, you can configure the maven plugin as follows:
- <plugin>
- <groupId>org.apache.sling</groupId>
- <artifactId>slingstart-maven-plugin</artifactId>
- <extensions>true</extensions>
- <version>1.3.4</version>
- <dependencies>
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.configadmin</artifactId>
- <version>1.8.4</version>
- </dependency>
- </dependencies>
- </plugin>
+<plugin>
+<groupId>org.apache.sling</groupId>
+<artifactId>slingstart-maven-plugin</artifactId>
+<extensions>true</extensions>
+<version>1.3.4</version>
+<dependencies>
+<dependency>
+<groupId>org.apache.felix</groupId>
+<artifactId>org.apache.felix.configadmin</artifactId>
+<version>1.8.4</version>
+</dependency>
+</dependencies>
+</plugin>
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/development/version-policy.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/version-policy.md b/content/documentation/development/version-policy.md
index 5c64fbc..a9e42ad 100644
--- a/content/documentation/development/version-policy.md
+++ b/content/documentation/development/version-policy.md
@@ -1,10 +1,7 @@
-title=TODO title for version-policy.md
-date=1900-01-01
-type=post
-tags=blog
+title=Version Policy
+type=page
status=published
~~~~~~
-Title: Version Policy
Excerpt: This page is about how we assign versions to exported packages and bundles and defines when to increase which part of the version number.
This page is about how we assign versions to exported packages and bundles and defines when to increase which part of the version number.
@@ -19,7 +16,7 @@ Please note that this page is currently in draft stage and still being discussed
In comments to [SLING-1176](https://issues.apache.org/jira/browse/SLING-2944) Ian Boston wrote:
-> The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably can't avoid this. \[...\] \[The problem is the\] manual maintenance of the version numbers. (not a big problem but needs to be done)
+> The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably can't avoid this. [...] [The problem is the] manual maintenance of the version numbers. (not a big problem but needs to be done)
I agree, that this is a problem. So let me reasonate on this a bit ;-)
@@ -78,12 +75,12 @@ The newest versions of the bnd library also support an `@Export` annotation in t
Using this syntax something like the following would be easily possible:
- /**
- * This is the Package Level JavaDoc
- */
- @Export(version = "1.0")
- package org.apache.sling.api.auth;
- import aQute.bnd.annotation.Export;
+/**
+* This is the Package Level JavaDoc
+*/
+@Export(version = "1.0")
+package org.apache.sling.api.auth;
+import aQute.bnd.annotation.Export;
See [bnd Versioning](http://bnd.bndtools.org/chapters/170-versioning.html) for details.
@@ -185,7 +182,7 @@ When importing packages a version number will automatically be generated by the
For example if importing the `api` package exported at version 1.2.3, the `Import-Package` statement is generated as
- Import-Package: api;version=[1.2.3,2.0.0)
+Import-Package: api;version=[1.2.3,2.0.0)
@@ -196,7 +193,7 @@ For bundles implementing the API, this default does not work well, since from th
For example implementing the `api` package exported at version 1.2.3, would require the following manually created `Import-Package` statement:
- Import-Package: api;version=[1.2.3,1.3.0)
+Import-Package: api;version=[1.2.3,1.3.0)
This allows for the implementation to work correctly with bug fixed package exports but as soon as there are any *externally visible* changes, the implementation bundle has to be adapted -- even if this just means increasing the upper version bound in the `Import-Package` statement thus guaranteeing compliance (again).
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/getting-started.md
----------------------------------------------------------------------
diff --git a/content/documentation/getting-started.md b/content/documentation/getting-started.md
index 5a8e005..5174498 100644
--- a/content/documentation/getting-started.md
+++ b/content/documentation/getting-started.md
@@ -1,10 +1,7 @@
-title=TODO title for getting-started.md
-date=1900-01-01
-type=post
-tags=blog
+title=Getting Started
+type=page
status=published
~~~~~~
-Title: Getting Started
We're on the way to update the documentation to make it more easy to get in touch with Sling. At the moment we can give you the following starting points:
@@ -13,7 +10,7 @@ We're on the way to update the documentation to make it more easy to get in touc
## Where to head from here
-We recommend you read through following topics to get as fast as possible into Sling:
+We recommend you read through following topics to get as fast as possible into Sling:
* [Getting and building Sling](/documentation/development/getting-and-building-sling.html)
* [Architecture](/documentation/the-sling-engine/architecture.html)
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/getting-started/discover-sling-in-15-minutes.md
----------------------------------------------------------------------
diff --git a/content/documentation/getting-started/discover-sling-in-15-minutes.md b/content/documentation/getting-started/discover-sling-in-15-minutes.md
index 7d61744..e2adb7f 100644
--- a/content/documentation/getting-started/discover-sling-in-15-minutes.md
+++ b/content/documentation/getting-started/discover-sling-in-15-minutes.md
@@ -1,10 +1,7 @@
-title=TODO title for discover-sling-in-15-minutes.md
-date=1900-01-01
-type=post
-tags=blog
+title=Discover Sling in 15 minutes
+type=page
status=published
~~~~~~
-Title: Discover Sling in 15 minutes
The Sling Launchpad is a ready-to-run Sling configuration, providing an embedded JCR content repository and web server, a selection of Sling components, documentation and examples. The Launchpad makes it easy to get started with Sling and to develop script-based applications.
@@ -17,10 +14,10 @@ While simple to run and understand, the Launchpad is a full-featured instance of
## See Also
-More Sling samples can be found under
+More Sling samples can be found under
[http://svn.apache.org/repos/asf/sling/trunk/samples/](http://svn.apache.org/repos/asf/sling/trunk/samples/)
-Once you grok the basic examples of this page, we recommend studying the
+Once you grok the basic examples of this page, we recommend studying the
*slingbucks* and *espblog* samples. Both have README files with more info.
## Prerequisites
@@ -37,7 +34,7 @@ A WebDAV client makes editing server-side scripts much more convenient, but to m
After downloading the Sling Launchpad self-runnable jar just start it as follows:
- $ java -jar org.apache.sling.launchpad-8.jar
+$ java -jar org.apache.sling.launchpad-8.jar
This starts the Sling embedded Web Server on port 8080 and writes application files into the `sling` folder found in the current working directory.
@@ -47,7 +44,7 @@ Once started, look at [http://localhost:8080/system/console/bundles](http://loca
On the bundles page, all bundles should be marked *Active*. They're all [OSGi](http://www.osgi.org/) bundles powered by [Apache Felix](http://felix.apache.org), but that doesn't really matter to us right now.
-*Log files: If things go wrong, have a look at the `sling/logs/error.log` log file \- that's where Sling writes any error messages.*
+*Log files: If things go wrong, have a look at the `sling/logs/error.log` log file - that's where Sling writes any error messages.*
## Create some content
@@ -56,16 +53,16 @@ Until we have ready-to-test forms, you can create content with cURL, or you can
To create a content node (nodes are a [JCR](http://jackrabbit.apache.org/) concept, a unit of storage) with cURL, use:
- curl -u admin:admin -F"sling:resourceType=foo/bar" -F"title=some title" http://localhost:8080/content/mynode
+curl -u admin:admin -F"sling:resourceType=foo/bar" -F"title=some title" http://localhost:8080/content/mynode
The resulting node can be seen at [http://localhost:8080/content/mynode.html](http://localhost:8080/content/mynode.html.path), or as json format under [http://localhost:8080/content/mynode.json](http://localhost:8080/content/mynode.json). Lets try with cURL:
- $ curl http://localhost:8080/content/mynode.json
+$ curl http://localhost:8080/content/mynode.json
-This returns the properties of the `/content/mynode` in JSON format as we have created it above.
+This returns the properties of the `/content/mynode` in JSON format as we have created it above.
- {"title":"some title","sling:resourceType":"foo/bar","jcr:primaryType":"nt:unstructured"}
+{"title":"some title","sling:resourceType":"foo/bar","jcr:primaryType":"nt:unstructured"}
The additional property `jcr:primaryType` is a special JCR property added by the content repository, indicating the JCR primary node type.
@@ -81,30 +78,30 @@ To select a script, Sling uses the node's *sling:resourceType* property, if it i
That is the case in our example, so the following script will be used by Sling to render the node in HTML, if the script is found at */apps/foo/bar/html.esp* in the repository.
- <html>
- <body>
- <h1><%= currentNode.title %></h1>
- </body>
- </html>
+<html>
+<body>
+<h1><%= currentNode.title %></h1>
+</body>
+</html>
To select the script, Sling:
* looks under */apps*
-* and appends the *sling:resourceType* value of our node ( which is *foo/bar* )
+* and appends the *sling:resourceType* value of our node ( which is *foo/bar* )
* and appends *html.esp*, as the extension of our URL is *html* and the language of our script is *esp*.
Store this script under */apps/foo/bar/html.esp*, either using a WebDAV client (connected to [http://admin:admin@localhost:8080/](http://admin:admin@localhost:8080/)), or using cURL as shown here, after creating the *html.esp* script in the current directory on your system:
- curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo
- curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo/bar
+curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo
+curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo/bar
create a local file *html.esp* and copy above content.
- curl -u admin:admin -T html.esp http://localhost:8080/apps/foo/bar/html.esp
+curl -u admin:admin -T html.esp http://localhost:8080/apps/foo/bar/html.esp
The HTML rendering of your node, at [http://localhost:8080/content/mynode.html](http://localhost:8080/content/mynode.html), is now created by this ESP script. You should see the node's title alone as an <h1> element in that page.
@@ -116,7 +113,7 @@ Servlets can also be easily "wired" to handle specific resource types, extension
## What next?
-These simple examples show how Sling uses scripts to work with JCR data, based
+These simple examples show how Sling uses scripts to work with JCR data, based
on *sling:resourceType* or node types.
There's much more to Sling of course - you'll find some additional simple examples below, as
@@ -133,19 +130,19 @@ In this case, the Sling response redirects to the URL of the created node.
Start by creating a new */blog* folder:
- curl -X POST -u admin:admin "http://localhost:8080/content/blog"
+curl -X POST -u admin:admin "http://localhost:8080/content/blog"
And create a node with a Sling-generated name under it:
- curl -D - -u admin:admin -F"title=Adventures with Sling" "http://localhost:8080/content/blog/"
+curl -D - -u admin:admin -F"title=Adventures with Sling" "http://localhost:8080/content/blog/"
Using cURL's *-D* option shows the full HTTP response, which includes a *Location* header to indicate where the new node was created:
- Location: /blog/adventures_with_slin
+Location: /blog/adventures_with_slin
The actual node name might not be *adventures_with_slin* - depending on existing content in your repository, Sling will find a unique name for this new node, based on several well-know property values like title, description, etc. which are used for this if provided.
@@ -165,52 +162,52 @@ Start by checking that [http://localhost:8080/content/mynode.html](http://localh
Create this script and name it *header.esp*:
- <div>
- <p style="color:blue;">
- <img src="/images/sling.jpg" align="right"/>
- <%= currentNode.headline %>
- </p>
- </div>
+<div>
+<p style="color:blue;">
+<img src="/images/sling.jpg" align="right"/>
+<%= currentNode.headline %>
+</p>
+</div>
Upload it so that it is used to render resources having *sling:resourceType=foo/header*:
- curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo/header/
- curl -u admin:admin -T header.esp http://localhost:8080/apps/foo/header/html.esp
+curl -X MKCOL -u admin:admin http://localhost:8080/apps/foo/header/
+curl -u admin:admin -T header.esp http://localhost:8080/apps/foo/header/html.esp
Create the header node:
- curl -u admin:admin -F"sling:resourceType=foo/header" -F"headline=Hello, Sling world" http://localhost:8080/content/header
+curl -u admin:admin -F"sling:resourceType=foo/header" -F"headline=Hello, Sling world" http://localhost:8080/content/header
Upload the logo that the script uses (using sling.jpg or another logo in the current directory):
- curl -X MKCOL -u admin:admin http://localhost:8080/images/
- curl -u admin:admin -T sling.jpg http://localhost:8080/images/sling.jpg
+curl -X MKCOL -u admin:admin http://localhost:8080/images/
+curl -u admin:admin -T sling.jpg http://localhost:8080/images/sling.jpg
And check that the header is rendered with the logo at [http://localhost:8080/content/header.html](http://localhost:8080/content/header.html).
Now, update the html.esp script that we created for our first example above, to include the header:
- <html>
- <body>
- <div id="header">
- <% sling.include("/content/header"); %>
- </div>
- <h1><%= currentNode.title %></h1>
- </body>
- </html>
+<html>
+<body>
+<div id="header">
+<% sling.include("/content/header"); %>
+</div>
+<h1><%= currentNode.title %></h1>
+</body>
+</html>
And upload it again to replace the previous version:
- curl -u admin:admin -T html.esp http://localhost:8080/apps/foo/bar/html.esp
+curl -u admin:admin -T html.esp http://localhost:8080/apps/foo/bar/html.esp
The [http://localhost:8080/content/mynode.html](http://localhost:8080/content/mynode.html), once refreshed, now shows the blue headline and logo, and this layout also applies to any node created with *sling:resourceType=foo/bar*.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/legacy/logging.md
----------------------------------------------------------------------
diff --git a/content/documentation/legacy/logging.md b/content/documentation/legacy/logging.md
index 836f256..021fcde 100644
--- a/content/documentation/legacy/logging.md
+++ b/content/documentation/legacy/logging.md
@@ -1,10 +1,7 @@
-title=TODO title for logging.md
-date=1900-01-01
-type=post
-tags=blog
+title=Logging
+type=page
status=published
~~~~~~
-Title: Logging
<div class="note">
This document is for 3.x release of Sling Commons Log components. Refer to
@@ -16,13 +13,13 @@ to newer version.
Logging in Sling is supported by the `org.apache.sling.commons.log` bundle, which is one of the first bundles installed and started by the Sling Launcher. The `org.apache.sling.commons.log` bundle has the following tasks:
- * Implements the OSGi Log Service Specification and registers the `LogService` and `LogReader` services
- * Exports three commonly used logging APIs:
- * [Simple Logging Facade for Java (SLF4J)](http://www.slf4j.org)
- * [Apache Commons Logging](http://jakarta.apache.org/commons/logging)
- * [log4j](http://logging.apache.org/log4j/index.html)
- * [java.util.logging](http://download.oracle.com/javase/6/docs/api/java/util/logging/package-summary.html) (as of r1169918)
- * Configures logging through our own implementation of the SLF4J backend API
+* Implements the OSGi Log Service Specification and registers the `LogService` and `LogReader` services
+* Exports three commonly used logging APIs:
+* [Simple Logging Facade for Java (SLF4J)](http://www.slf4j.org)
+* [Apache Commons Logging](http://jakarta.apache.org/commons/logging)
+* [log4j](http://logging.apache.org/log4j/index.html)
+* [java.util.logging](http://download.oracle.com/javase/6/docs/api/java/util/logging/package-summary.html) (as of r1169918)
+* Configures logging through our own implementation of the SLF4J backend API
## Initial Configuration
@@ -36,7 +33,7 @@ The `org.apache.sling.commons.log` bundle gets the initial configuration from th
| `org.apache.sling.commons.log.file` | undefined | Sets the log file to which log messages are written. If this property is empty or missing, log messages are written to `System.out`. |
| `org.apache.sling.commons.log.file.number` | 5 | The number of rotated files to keep. |
| `org.apache.sling.commons.log.file.size` | '.'yyyy-MM-dd | Defines how the log file is rotated (by schedule or by size) and when to rotate. See the section *Log File Rotation* below for full details on log file rotation. |
-| `org.apache.sling.commons.log.pattern` | \{0,date,dd.MM.yyyy HH:mm:ss.SSS\} \*\{4\}\* \[\{2\}\]({{ refs.-2.path }}) \{3\} \{5\} | The `MessageFormat` pattern to use for formatting log messages with the root logger. |
+| `org.apache.sling.commons.log.pattern` | {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}]({{ refs.-2.path }}) {3} {5} | The `MessageFormat` pattern to use for formatting log messages with the root logger. |
| `org.apache.sling.commons.log.julenabled` | n/a | Enables the `java.util.logging` support. |
@@ -55,11 +52,11 @@ The following properties may be set:
|--|--|--|--|
| `org.apache.sling.commons.log.level` | `String` | `INFO` | Sets the logging level of the loggers. This may be any of the defined logging levels `DEBUG`, `INFO`, `WARN`, `ERROR` and `FATAL`. |
| `org.apache.sling.commons.log.file` | `String` | undefined | Sets the log file to which log messages are written. If this property is empty or missing, log messages are written to `System.out`. This property should refer to the file name of a configured Log Writer (see below). If no Log Writer is configured with the same file name an implicit Log Writer configuration with default configuration is created. |
-| `org.apache.sling.commons.log.pattern` | `String` | \{0,date,dd.MM.yyyy HH:mm:ss.SSS\} \*\{4\}\* \[\{2\}\]({{ refs.-2.path }}) \{3\} \{5\} | The `java.util.MessageFormat` pattern to use for formatting log messages with the root logger. This is a `java.util.MessageFormat` pattern supporting up to six arguments: \{0\} The timestamp of type `java.util.Date`, \{1\} the log marker, \{2\} the name of the current thread, \{3\} the name of the logger, \{4\} the debug level and \{5\} the actual debug message. If the log call includes a Throwable, the stacktrace is just appended to the message regardless of the pattern. |
-| `org.apache.sling.commons.log.names` | `String\[\]` | -- | A list of logger names to which this configuration applies. |
+| `org.apache.sling.commons.log.pattern` | `String` | {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}]({{ refs.-2.path }}) {3} {5} | The `java.util.MessageFormat` pattern to use for formatting log messages with the root logger. This is a `java.util.MessageFormat` pattern supporting up to six arguments: {0} The timestamp of type `java.util.Date`, {1} the log marker, {2} the name of the current thread, {3} the name of the logger, {4} the debug level and {5} the actual debug message. If the log call includes a Throwable, the stacktrace is just appended to the message regardless of the pattern. |
+| `org.apache.sling.commons.log.names` | `String[]` | -- | A list of logger names to which this configuration applies. |
-Note that multiple Logger Configurations may refer to the same Log Writer Configuration. If no Log Writer Configuration exists whose file name matches the file name set on the Logger Configuration an implicit Log Writer Configuration with default setup (daily log rotation) is internally created.
+Note that multiple Logger Configurations may refer to the same Log Writer Configuration. If no Log Writer Configuration exists whose file name matches the file name set on the Logger Configuration an implicit Log Writer Configuration with default setup (daily log rotation) is internally created.
### Log Writer Configuration
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/pax-exam-utils.md
----------------------------------------------------------------------
diff --git a/content/documentation/pax-exam-utils.md b/content/documentation/pax-exam-utils.md
index a455149..49dbad7 100644
--- a/content/documentation/pax-exam-utils.md
+++ b/content/documentation/pax-exam-utils.md
@@ -1,10 +1,7 @@
-title=TODO title for pax-exam-utils.md
-date=1900-01-01
-type=post
-tags=blog
+title=Sling Pax Exam Utilities
+type=page
status=published
~~~~~~
-Title: Sling Pax Exam Utilities
Utilities to help testing Sling components with Pax Exam are available at
[https://svn.apache.org/repos/asf/sling/trunk/testing/sling-pax-util](https://svn.apache.org/repos/asf/sling/trunk/testing/sling-pax-util)
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine.md b/content/documentation/the-sling-engine.md
index 109518c..933937e 100644
--- a/content/documentation/the-sling-engine.md
+++ b/content/documentation/the-sling-engine.md
@@ -1,10 +1,7 @@
-title=TODO title for the-sling-engine.md
-date=1900-01-01
-type=post
-tags=blog
+title=The Sling Engine
+type=page
status=published
~~~~~~
-Title: The Sling Engine
## General
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/adapters.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/adapters.md b/content/documentation/the-sling-engine/adapters.md
index e3ebb3b..c56ba98 100644
--- a/content/documentation/the-sling-engine/adapters.md
+++ b/content/documentation/the-sling-engine/adapters.md
@@ -1,10 +1,7 @@
-title=TODO title for adapters.md
-date=1900-01-01
-type=post
-tags=blog
+title=Adapters
+type=page
status=published
~~~~~~
-Title: Adapters
[TOC]
@@ -18,26 +15,26 @@ To use resources as scripts, the `Resource.adaptTo` method must support being ca
The `Adaptable` interface defines the API to be implemented by a class providing adaptability to another class. The single method defined by this interface is
- /**
- * Adapts the adaptable to another type.
- * <p>
- * Please not that it is explicitly left as an implementation detail whether
- * each call to this method with the same <code>type</code> yields the same
- * object or a new object on each call.
- * <p>
- * Implementations of this method should document their adapted types as
- * well as their behaviour with respect to returning newly created or not
- * instance on each call.
- *
- * @param <AdapterType> The generic type to which this resource is adapted
- * to
- * @param type The Class object of the target type, such as
- * <code>javax.jcr.Node.class</code> or
- * <code>java.io.File.class</code>
- * @return The adapter target or <code>null</code> if the resource cannot
- * adapt to the requested type
- */
- <AdapterType> AdapterType adaptTo(Class<AdapterType> type);
+/**
+* Adapts the adaptable to another type.
+* <p>
+* Please not that it is explicitly left as an implementation detail whether
+* each call to this method with the same <code>type</code> yields the same
+* object or a new object on each call.
+* <p>
+* Implementations of this method should document their adapted types as
+* well as their behaviour with respect to returning newly created or not
+* instance on each call.
+*
+* @param <AdapterType> The generic type to which this resource is adapted
+* to
+* @param type The Class object of the target type, such as
+* <code>javax.jcr.Node.class</code> or
+* <code>java.io.File.class</code>
+* @return The adapter target or <code>null</code> if the resource cannot
+* adapt to the requested type
+*/
+<AdapterType> AdapterType adaptTo(Class<AdapterType> type);
This method is called to get a view of the same object in terms of another class. Examples of implementations of this method are the Sling `ResourceResolver` implementation providing adapting to a JCR session and the Sling JCR based `Resource` implementation providing adapting to a JCR node.
@@ -50,30 +47,30 @@ The web console plugin evaluates metadata being provided by any `AdapterFactory`
# Implementing Adaptable
-Each adaptable should derive from `SlingAdaptable` to automatically profit from all according `AdapterFactories` registered in the system.
-In case the `adaptTo(...)` method is being overwritten an according `SLING-INF/adapters.json` should be included in the providing bundle
-listing all adaptation possibilities. While this file is not strictly necessary for the actual adaptation to work, it provides useful information to the Web Console plugin.
+Each adaptable should derive from `SlingAdaptable` to automatically profit from all according `AdapterFactories` registered in the system.
+In case the `adaptTo(...)` method is being overwritten an according `SLING-INF/adapters.json` should be included in the providing bundle
+listing all adaptation possibilities. While this file is not strictly necessary for the actual adaptation to work, it provides useful information to the Web Console plugin.
Otherwise developers will not know which adaptations are supported. The format of this JSON file looks like this ([SLING-2295](https://issues.apache.org/jira/browse/SLING-2295)):
- {
- <fully qualified class name of adaptable> : {
- <condition> : <fully qualified class name of adapter, may be a JSON array>
- }
- }
+{
+<fully qualified class name of adaptable> : {
+<condition> : <fully qualified class name of adapter, may be a JSON array>
+}
+}
For example
- {
- "org.apache.sling.api.resource.Resource" : {
- "If the adaptable is a AuthorizableResource." : [
- "java.util.Map",
- "org.apache.sling.api.resource.ValueMap",
- "org.apache.jackrabbit.api.security.user.Authorizable"
- ],
- "If the resource is an AuthorizableResource and represents a JCR User" : "org.apache.jackrabbit.api.security.user.User",
- "If the resource is an AuthorizableResource and represents a JCR Group" : "org.apache.jackrabbit.api.security.user.Group"
- }
- }
+{
+"org.apache.sling.api.resource.Resource" : {
+"If the adaptable is a AuthorizableResource." : [
+"java.util.Map",
+"org.apache.sling.api.resource.ValueMap",
+"org.apache.jackrabbit.api.security.user.Authorizable"
+],
+"If the resource is an AuthorizableResource and represents a JCR User" : "org.apache.jackrabbit.api.security.user.User",
+"If the resource is an AuthorizableResource and represents a JCR Group" : "org.apache.jackrabbit.api.security.user.Group"
+}
+}
Instead of manually creating that JSON file, the annotations from the module [adapter-annotations](https://svn.apache.org/viewvc/sling/trunk/tooling/maven/adapter-annotations/) can be used together with the goal `generate-adapter-metadata` from the [Maven Sling Plugin](http://sling.apache.org/components/maven-sling-plugin/generate-adapter-metadata-mojo.html) to generate it automatically ([SLING-2313](https://issues.apache.org/jira/browse/SLING-2313)).
@@ -82,9 +79,9 @@ Instead of manually creating that JSON file, the annotations from the module [ad
Sometimes an `Adaptable` implementation cannot foresee future uses and requirements. To cope with such extensibility requirements two interfaces and an abstract base class are defined:
- * `AdapterManager`
- * `AdapterFactory`
- * `SlingAdaptable`
+* `AdapterManager`
+* `AdapterFactory`
+* `SlingAdaptable`
## AdapterFactory
@@ -92,31 +89,31 @@ Sometimes an `Adaptable` implementation cannot foresee future uses and requireme
The `AdapterFactory` interface defines the service interface and API for factories supporting extensible adapters for `SlingAdaptable` objects. The interface has a single method:
- /**
- * Adapt the given object to the adaptable type. The adaptable object is
- * guaranteed to be an instance of one of the classes listed in the
- * {@link #ADAPTABLE_CLASSES} services registration property. The type
- * parameter is one of the classes listed in the {@link #ADAPTER_CLASSES}
- * service registration properties.
- * <p>
- * This method may return <code>null</code> if the adaptable object cannot
- * be adapted to the adapter (target) type for any reason. In this case, the
- * implementation should log a message to the log facility noting the cause
- * for not being able to adapt.
- * <p>
- * Note that the <code>adaptable</code> object is not required to implement
- * the <code>Adaptable</code> interface, though most of the time this method
- * is called by means of calling the {@link Adaptable#adaptTo(Class)}
- * method.
- *
- * @param <AdapterType> The generic type of the adapter (target) type.
- * @param adaptable The object to adapt to the adapter type.
- * @param type The type to which the object is to be adapted.
- * @return The adapted object or <code>null</code> if this factory instance
- * cannot adapt the object.
- */
- <AdapterType> AdapterType getAdapter(Object adaptable,
- Class<AdapterType> type);
+/**
+* Adapt the given object to the adaptable type. The adaptable object is
+* guaranteed to be an instance of one of the classes listed in the
+* {@link #ADAPTABLE_CLASSES} services registration property. The type
+* parameter is one of the classes listed in the {@link #ADAPTER_CLASSES}
+* service registration properties.
+* <p>
+* This method may return <code>null</code> if the adaptable object cannot
+* be adapted to the adapter (target) type for any reason. In this case, the
+* implementation should log a message to the log facility noting the cause
+* for not being able to adapt.
+* <p>
+* Note that the <code>adaptable</code> object is not required to implement
+* the <code>Adaptable</code> interface, though most of the time this method
+* is called by means of calling the {@link Adaptable#adaptTo(Class)}
+* method.
+*
+* @param <AdapterType> The generic type of the adapter (target) type.
+* @param adaptable The object to adapt to the adapter type.
+* @param type The type to which the object is to be adapted.
+* @return The adapted object or <code>null</code> if this factory instance
+* cannot adapt the object.
+*/
+<AdapterType> AdapterType getAdapter(Object adaptable,
+Class<AdapterType> type);
Implementations of this interface are registered as OSGi services providing two lists: The list of classes which may be adapted (property named `adaptables`) and the list of classes to which the adapted class may be adapted (property named `adapters`). A good example of an Class implementing `AdapterFactory` is the `SlingScriptAdapterFactory`. In addition a property named `adapter.condition` can be provided which is supposed to contain a string value explaining under which circumstances the adaption will work (if there are any restrictions). This is evaluated by the Web Console Plugin.
@@ -131,23 +128,23 @@ The `AdapterManager` is defines the service interface for the generalized and ex
The `AdapterManager` interface is defined as follows:
- /**
- * Returns an adapter object of the requested <code>AdapterType</code> for
- * the given <code>adaptable</code> object.
- * <p>
- * The <code>adaptable</code> object may be any non-<code>null</code> object
- * and is not required to implement the <code>Adaptable</code> interface.
- *
- * @param <AdapterType> The generic type of the adapter (target) type.
- * @param adaptable The object to adapt to the adapter type.
- * @param type The type to which the object is to be adapted.
- * @return The adapted object or <code>null</code> if no factory exists to
- * adapt the <code>adaptable</code> to the <code>AdapterType</code>
- * or if the <code>adaptable</code> cannot be adapted for any other
- * reason.
- */
- <AdapterType> AdapterType getAdapter(Object adaptable,
- Class<AdapterType> type);
+/**
+* Returns an adapter object of the requested <code>AdapterType</code> for
+* the given <code>adaptable</code> object.
+* <p>
+* The <code>adaptable</code> object may be any non-<code>null</code> object
+* and is not required to implement the <code>Adaptable</code> interface.
+*
+* @param <AdapterType> The generic type of the adapter (target) type.
+* @param adaptable The object to adapt to the adapter type.
+* @param type The type to which the object is to be adapted.
+* @return The adapted object or <code>null</code> if no factory exists to
+* adapt the <code>adaptable</code> to the <code>AdapterType</code>
+* or if the <code>adaptable</code> cannot be adapted for any other
+* reason.
+*/
+<AdapterType> AdapterType getAdapter(Object adaptable,
+Class<AdapterType> type);
Any object can theoretically be adapted to any class even if it does not implement the `Adaptable` interface, if an `AdapterFactory` service delivers a `getAdapter()` method which adapts an object to another one. To check if there's any existing `AdapterFactory` which can adapt a given object to another one the `AdapterManager` service with its `getAdapter()` method does the job. So the `Adaptable` interface merely is an indicator that the object provides built-in support for being adapted.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/architecture.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/architecture.md b/content/documentation/the-sling-engine/architecture.md
index bcf6a9f..d0cb977 100644
--- a/content/documentation/the-sling-engine/architecture.md
+++ b/content/documentation/the-sling-engine/architecture.md
@@ -1,10 +1,7 @@
-title=TODO title for architecture.md
-date=1900-01-01
-type=post
-tags=blog
+title=Architecture
+type=page
status=published
~~~~~~
-Title: Architecture
The following is a short list of high-lights of Sling:
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/authentication.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication.md b/content/documentation/the-sling-engine/authentication.md
index 5630bb0..f09b223 100644
--- a/content/documentation/the-sling-engine/authentication.md
+++ b/content/documentation/the-sling-engine/authentication.md
@@ -1,10 +1,7 @@
-title=TODO title for authentication.md
-date=1900-01-01
-type=post
-tags=blog
+title=Authentication
+type=page
status=published
~~~~~~
-Title: Authentication
Excerpt: How requests are authenticated.
@@ -15,7 +12,7 @@ Let's look at generic request processing of Sling: Sling is linked into the outs
This method is called by the OSGi HTTP Service implementation after the servlet has been selected to handle the request but before actually calling the servlet's `service` method.
<a href="authentication.png" style="float:left;padding-right:5%">
- <img src="authentication.png" title="Authentication Flow" alt="Authentication Flow" />
+<img src="authentication.png" title="Authentication Flow" alt="Authentication Flow" />
</a>
1. First the OSGi HTTP Service implementation is analyzing the request URL to find a match for a servlet or resource registered with the HTTP Service.
@@ -26,7 +23,7 @@ The important thing to note here is, that at the time the `handleSecurity` metho
The following pages describe the full details of request authentication in Sling in full detail:
-* [Tasks](/documentation/the-sling-engine/authentication/authentication-tasks.html): {{ refs.authentication-tasks.headers.excerpt }}
-* [Actors](/documentation/the-sling-engine/authentication/authentication-actors.html): {{ refs.authentication-actors.headers.excerpt }}
-* [Framework](/documentation/the-sling-engine/authentication/authentication-framework.html): {{ refs.authentication-framework.headers.excerpt }}
-* [AuthenticationHandler](/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html): {{ refs.authentication-authenticationhandler.headers.excerpt }}
+* [Tasks](/documentation/the-sling-engine/authentication/authentication-tasks.html): {{ refs.authentication-tasks.headers.excerpt }}
+* [Actors](/documentation/the-sling-engine/authentication/authentication-actors.html): {{ refs.authentication-actors.headers.excerpt }}
+* [Framework](/documentation/the-sling-engine/authentication/authentication-framework.html): {{ refs.authentication-framework.headers.excerpt }}
+* [AuthenticationHandler](/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html): {{ refs.authentication-authenticationhandler.headers.excerpt }}
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/authentication/authentication-actors.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-actors.md b/content/documentation/the-sling-engine/authentication/authentication-actors.md
index 63ee269..63a44f9 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-actors.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-actors.md
@@ -1,10 +1,7 @@
-title=TODO title for authentication-actors.md
-date=1900-01-01
-type=post
-tags=blog
+title=Authentication - Actors
+type=page
status=published
~~~~~~
-Title: Authentication - Actors
Excerpt: The authentication process involves a number of actors contributing to the concepts, the API and the particular implementations.
The authentication process involves a number of actors contributing to the concepts, the API and the particular implementations.
@@ -32,32 +29,32 @@ That's all there is for the Sling Engine to do with respect to authentication.
The support for authenticating client requests is implemented in the Sling Auth Core bundle. As such this bundle provides three areas of support
- * `AuthenticationHandler` service interface. This is implemented by services providing functionality to extract credentials from HTTP requests.
- * `Authenticator` service interface. This is implemented by the `SlingAuthenticator` class in the Sling Auth Core bundle and provides applications with entry points to login and logout.
- * `AuthenticationSupport` service interface. This is implemented by the `SlingAuthenticator` class in the Sling Auth Core bundle and allows applications registering with the OSGi HTTP Service to make use of the Sling authentication infrastructure.
+* `AuthenticationHandler` service interface. This is implemented by services providing functionality to extract credentials from HTTP requests.
+* `Authenticator` service interface. This is implemented by the `SlingAuthenticator` class in the Sling Auth Core bundle and provides applications with entry points to login and logout.
+* `AuthenticationSupport` service interface. This is implemented by the `SlingAuthenticator` class in the Sling Auth Core bundle and allows applications registering with the OSGi HTTP Service to make use of the Sling authentication infrastructure.
## JCR Repository
The actual process of logging into the repository and provided a `Session` is implementation dependent. In the case of Jackrabbit extensibility is provided by configuration of the Jackrabbit repository by means of an interface and two helper classes:
- * `LoginModule` -- The interface to be implemented to provide login processing plugins
- * `AbstractLoginModule` -- A an abstract base class implementation of the `LoginModule` interface.
- * `DefaultLoginModule` -- The default implementation of the `AbstractLoginModule` provided by Jackabbit. This login module takes `SimpleCredentials` and uses the repository to lookup the users, validate the credentials and providing the `Principal` representing the user towards the repository.
+* `LoginModule` -- The interface to be implemented to provide login processing plugins
+* `AbstractLoginModule` -- A an abstract base class implementation of the `LoginModule` interface.
+* `DefaultLoginModule` -- The default implementation of the `AbstractLoginModule` provided by Jackabbit. This login module takes `SimpleCredentials` and uses the repository to lookup the users, validate the credentials and providing the `Principal` representing the user towards the repository.
The Sling Jackrabbit Embedded Repository bundle provides additional plugin interfaces to extend the login process dynamically using OSGi services. To this avail the bundle configures a `LoginModule` with the provided default Jackrabbit configuration supporting these plugins:
- * `LoginModulePlugin` -- The main service interface. Plugins must implement this interface to be able to extend the login process. See for example the [Sling OpenID authentication handler](http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/openid/), which implements this interface to support OpenID authentication.
- * `AuthenticationPlugin` -- Helper interface for the `LoginModulePlugin`.
+* `LoginModulePlugin` -- The main service interface. Plugins must implement this interface to be able to extend the login process. See for example the [Sling OpenID authentication handler](http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/openid/), which implements this interface to support OpenID authentication.
+* `AuthenticationPlugin` -- Helper interface for the `LoginModulePlugin`.
## Sling Applications
Sling Applications requiring authenticated requests should not care about how authentication is implemented. To support such functionality the `Authenticator` service is provided with two methods:
- * `login` -- allows the application to ensure requests are authenticated. This involves selecting an `AuthenticationHandler` to request credentials for authentication.
+* `login` -- allows the application to ensure requests are authenticated. This involves selecting an `AuthenticationHandler` to request credentials for authentication.
- * `logout` -- allows the application to forget about any authentication. This involves selecting an `AuthenticationHandler` to forget about credentials in the request.
+* `logout` -- allows the application to forget about any authentication. This involves selecting an `AuthenticationHandler` to forget about credentials in the request.
Sling Applications should never directly use any knowledge of any authentication handler or directly call into an authentication handler. This will certainly break the application and cause unexpected behaviour.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
index 4235048..52fecf9 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
@@ -1,10 +1,7 @@
-title=TODO title for authentication-authenticationhandler.md
-date=1900-01-01
-type=post
-tags=blog
+title=Authentication - AuthenticationHandler
+type=page
status=published
~~~~~~
-Title: Authentication - AuthenticationHandler
Excerpt: The `AuthenticationHandler` interface defines the service API which may be implemented by authentication handlers registered as OSGi services.
The `AuthenticationHandler` interface defines the service API which may be implemented by authentication handlers registered as OSGi services.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/form-based-authenticationhandler.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/form-based-authenticationhandler.md b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/form-based-authenticationhandler.md
index 9874c95..8f1ee41 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/form-based-authenticationhandler.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/form-based-authenticationhandler.md
@@ -1,10 +1,7 @@
-title=TODO title for form-based-authenticationhandler.md
-date=1900-01-01
-type=post
-tags=blog
+title=Form Based AuthenticationHandler
+type=page
status=published
~~~~~~
-Title: Form Based AuthenticationHandler
[TOC]
@@ -77,15 +74,15 @@ The Form Based Authentication Handler contains a [default form servlet](http://s
After the successful authentication of the user in phase 1, the authentication state is stored in a Cookie or an HTTP Session. The stored value is a security token with the following contents:
- HmacSHA1(securetoken, <securetokennumber><expirytime>@<userID>)@<securetokennumber><expirytime>@<userID>
+HmacSHA1(securetoken, <securetokennumber><expirytime>@<userID>)@<securetokennumber><expirytime>@<userID>
The `securetoken` and `securetokennumber` are related in that an table of secure tokens is maintained where the `securetoken` is an entry in the table and the `securetokennumber` is the index in of the token in the table.
The secure tokens are refreshed periodically causing the authentication state stored in the Cookie or the HTTP Session to be updated peridocally. This periodic update has two advantages:
- * Login sessions time out after some period of inactivity: If a request is handled for an authentication state whose expiry time has passed, the request is considered unauthenticated.
- * If a Cookie would be stolen or an HTTP Session be hijacked, the authentication state expires within a reasonable amount of time to try to prevent stealing the authentication.
+* Login sessions time out after some period of inactivity: If a request is handled for an authentication state whose expiry time has passed, the request is considered unauthenticated.
+* If a Cookie would be stolen or an HTTP Session be hijacked, the authentication state expires within a reasonable amount of time to try to prevent stealing the authentication.
The authentication state may be transmitted with a Cookie which is configured as follows:
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/openid-authenticationhandler.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/openid-authenticationhandler.md b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/openid-authenticationhandler.md
index 463f393..09f6dab 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/openid-authenticationhandler.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler/openid-authenticationhandler.md
@@ -1,10 +1,7 @@
-title=TODO title for openid-authenticationhandler.md
-date=1900-01-01
-type=post
-tags=blog
+title=OpenID AuthenticationHandler
+type=page
status=published
~~~~~~
-Title: OpenID AuthenticationHandler
[TOC]
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/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
index 15baf15..c5a3b2c 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-framework.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-framework.md
@@ -1,19 +1,16 @@
-title=TODO title for authentication-framework.md
-date=1900-01-01
-type=post
-tags=blog
+title=Authentication - Framework
+type=page
status=published
~~~~~~
-Title: Authentication - Framework
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.
+* 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.
@@ -48,7 +45,7 @@ Extracting the credentials and trying to login to the repository may yield the f
| 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.
+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>
@@ -67,7 +64,7 @@ The `handleSecurity` method gets credentials from the `AuthenticationHandler` an
**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);
+Session session = request.getResourceResolver().adaptTo(Session.class);
@@ -85,13 +82,13 @@ The values set on the *Authentication Requirements* configuration property or th
**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
+* /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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/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
index 8af499f..ebf775e 100644
--- a/content/documentation/the-sling-engine/authentication/authentication-tasks.md
+++ b/content/documentation/the-sling-engine/authentication/authentication-tasks.md
@@ -1,27 +1,24 @@
-title=TODO title for authentication-tasks.md
-date=1900-01-01
-type=post
-tags=blog
+title=Authentication - Tasks
+type=page
status=published
~~~~~~
-Title: Authentication - Tasks
Excerpt: Authentication of HTTP Requests is generally a two-step process: First the credentials must be extracted from the request and second the credentials must be validated. In the case of Sling this means acquiring a JCR Session.
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
+* 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.
+* 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/88e80480/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
index 703b243..fd88767 100644
--- a/content/documentation/the-sling-engine/default-mapping-and-rendering.md
+++ b/content/documentation/the-sling-engine/default-mapping-and-rendering.md
@@ -1,10 +1,7 @@
-title=TODO title for default-mapping-and-rendering.md
-date=1900-01-01
-type=post
-tags=blog
+title=Default Mapping and Rendering
+type=page
status=published
~~~~~~
translation_pending: true
-Title: Default Mapping and Rendering
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/88e80480/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
index 1c0188f..7a9b465 100644
--- a/content/documentation/the-sling-engine/dispatching-requests.md
+++ b/content/documentation/the-sling-engine/dispatching-requests.md
@@ -1,10 +1,7 @@
-title=TODO title for dispatching-requests.md
-date=1900-01-01
-type=post
-tags=blog
+title=Dispatching Requests
+type=page
status=published
~~~~~~
-Title: Dispatching Requests
## Main process
@@ -18,23 +15,23 @@ The following steps should give you an overview how a request is processed in Sl
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. 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. 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. 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`
+* 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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/88e80480/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
index 3e25dee..74e65b9 100644
--- a/content/documentation/the-sling-engine/errorhandling.md
+++ b/content/documentation/the-sling-engine/errorhandling.md
@@ -1,10 +1,7 @@
-title=TODO title for errorhandling.md
-date=1900-01-01
-type=post
-tags=blog
+title=Errorhandling
+type=page
status=published
~~~~~~
-Title: Errorhandling
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.
@@ -12,7 +9,7 @@ The Sling Servlet Resolver bundle implements this interface by providing an elab
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
+The [ErrorHandlingTest][1] in our integration tests suite provides
working examples of various error handling scenarios.
[TOC]
@@ -24,12 +21,12 @@ 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)
+* 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.
+* 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
@@ -38,13 +35,13 @@ The Sling engine implements the `HttpServletResponse.sendError` methods by calli
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.
+* 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`.
+* 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
@@ -60,13 +57,13 @@ To register a catch-all handler for any uncaught Throwables you might create a s
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
+* 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
+[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/88e80480/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
index 38f9dd6..180368c 100644
--- a/content/documentation/the-sling-engine/featureflags.md
+++ b/content/documentation/the-sling-engine/featureflags.md
@@ -1,22 +1,19 @@
-title=TODO title for featureflags.md
-date=1900-01-01
-type=post
-tags=blog
+title=Feature Flags
+type=page
status=published
~~~~~~
-Title: Feature Flags
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
+* 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