http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/development/slingstart.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/slingstart.md 
b/content/documentation/development/slingstart.md
index 88cd698..ff62e85 100644
--- a/content/documentation/development/slingstart.md
+++ b/content/documentation/development/slingstart.md
@@ -1,7 +1,10 @@
-title=The Apache Sling Provisioning Model and Apache SlingStart                
-type=page
+title=TODO title for slingstart.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: The Apache Sling Provisioning Model and Apache SlingStart
 
 [TOC]
 
@@ -16,14 +19,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
 
@@ -32,10 +35,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
@@ -46,18 +49,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
 
@@ -65,22 +68,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.
 
@@ -92,65 +95,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
@@ -161,17 +164,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:
 
@@ -192,9 +195,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
@@ -206,9 +209,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.
 
@@ -216,9 +219,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.
 
@@ -230,12 +233,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:
 
@@ -244,14 +247,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.
 
@@ -259,28 +262,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".
 
@@ -316,7 +319,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).
 
@@ -330,17 +333,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/53c84cf9/content/documentation/development/version-policy.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/version-policy.md 
b/content/documentation/development/version-policy.md
index a9e42ad..5c64fbc 100644
--- a/content/documentation/development/version-policy.md
+++ b/content/documentation/development/version-policy.md
@@ -1,7 +1,10 @@
-title=Version Policy           
-type=page
+title=TODO title for version-policy.md 
+date=1900-01-01
+type=post
+tags=blog
 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.
@@ -16,7 +19,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 ;-)
 
@@ -75,12 +78,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.
@@ -182,7 +185,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)
 
 
 
@@ -193,7 +196,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/53c84cf9/content/documentation/getting-started.md
----------------------------------------------------------------------
diff --git a/content/documentation/getting-started.md 
b/content/documentation/getting-started.md
index 5174498..5a8e005 100644
--- a/content/documentation/getting-started.md
+++ b/content/documentation/getting-started.md
@@ -1,7 +1,10 @@
-title=Getting Started          
-type=page
+title=TODO title for getting-started.md 
+date=1900-01-01
+type=post
+tags=blog
 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:
 
@@ -10,7 +13,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/53c84cf9/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 e2adb7f..7d61744 100644
--- a/content/documentation/getting-started/discover-sling-in-15-minutes.md
+++ b/content/documentation/getting-started/discover-sling-in-15-minutes.md
@@ -1,7 +1,10 @@
-title=Discover Sling in 15 minutes             
-type=page
+title=TODO title for discover-sling-in-15-minutes.md 
+date=1900-01-01
+type=post
+tags=blog
 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.
 
@@ -14,10 +17,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
@@ -34,7 +37,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.
@@ -44,7 +47,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
 
@@ -53,16 +56,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.
 
@@ -78,30 +81,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 
&lt;h1&gt; element in that page.
@@ -113,7 +116,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
@@ -130,19 +133,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.
@@ -162,52 +165,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/53c84cf9/content/documentation/legacy/logging.md
----------------------------------------------------------------------
diff --git a/content/documentation/legacy/logging.md 
b/content/documentation/legacy/logging.md
index 021fcde..836f256 100644
--- a/content/documentation/legacy/logging.md
+++ b/content/documentation/legacy/logging.md
@@ -1,7 +1,10 @@
-title=Logging          
-type=page
+title=TODO title for logging.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: Logging
 
 <div class="note">
 This document is for 3.x release of Sling Commons Log components. Refer to
@@ -13,13 +16,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
@@ -33,7 +36,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. |
 
 
@@ -52,11 +55,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/53c84cf9/content/documentation/pax-exam-utils.md
----------------------------------------------------------------------
diff --git a/content/documentation/pax-exam-utils.md 
b/content/documentation/pax-exam-utils.md
index 49dbad7..a455149 100644
--- a/content/documentation/pax-exam-utils.md
+++ b/content/documentation/pax-exam-utils.md
@@ -1,7 +1,10 @@
-title=Sling Pax Exam Utilities         
-type=page
+title=TODO title for pax-exam-utils.md 
+date=1900-01-01
+type=post
+tags=blog
 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/53c84cf9/content/documentation/the-sling-engine.md
----------------------------------------------------------------------
diff --git a/content/documentation/the-sling-engine.md 
b/content/documentation/the-sling-engine.md
index 933937e..109518c 100644
--- a/content/documentation/the-sling-engine.md
+++ b/content/documentation/the-sling-engine.md
@@ -1,7 +1,10 @@
-title=The Sling Engine         
-type=page
+title=TODO title for the-sling-engine.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: The Sling Engine
 
 ## General
 

http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/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 c56ba98..e3ebb3b 100644
--- a/content/documentation/the-sling-engine/adapters.md
+++ b/content/documentation/the-sling-engine/adapters.md
@@ -1,7 +1,10 @@
-title=Adapters         
-type=page
+title=TODO title for adapters.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: Adapters
 
 [TOC]
 
@@ -15,26 +18,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.
@@ -47,30 +50,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)).
 
@@ -79,9 +82,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
@@ -89,31 +92,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.
@@ -128,23 +131,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/53c84cf9/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 d0cb977..bcf6a9f 100644
--- a/content/documentation/the-sling-engine/architecture.md
+++ b/content/documentation/the-sling-engine/architecture.md
@@ -1,7 +1,10 @@
-title=Architecture             
-type=page
+title=TODO title for architecture.md 
+date=1900-01-01
+type=post
+tags=blog
 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/53c84cf9/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 f09b223..5630bb0 100644
--- a/content/documentation/the-sling-engine/authentication.md
+++ b/content/documentation/the-sling-engine/authentication.md
@@ -1,7 +1,10 @@
-title=Authentication           
-type=page
+title=TODO title for authentication.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: Authentication
 Excerpt:  How requests are authenticated.
 
 
@@ -12,7 +15,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.
@@ -23,7 +26,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/53c84cf9/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 63a44f9..63ee269 100644
--- 
a/content/documentation/the-sling-engine/authentication/authentication-actors.md
+++ 
b/content/documentation/the-sling-engine/authentication/authentication-actors.md
@@ -1,7 +1,10 @@
-title=Authentication - Actors          
-type=page
+title=TODO title for authentication-actors.md 
+date=1900-01-01
+type=post
+tags=blog
 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.
@@ -29,32 +32,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/53c84cf9/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 52fecf9..4235048 100644
--- 
a/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
+++ 
b/content/documentation/the-sling-engine/authentication/authentication-authenticationhandler.md
@@ -1,7 +1,10 @@
-title=Authentication - AuthenticationHandler           
-type=page
+title=TODO title for authentication-authenticationhandler.md 
+date=1900-01-01
+type=post
+tags=blog
 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/53c84cf9/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 8f1ee41..9874c95 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,7 +1,10 @@
-title=Form Based AuthenticationHandler         
-type=page
+title=TODO title for form-based-authenticationhandler.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: Form Based AuthenticationHandler
 
 [TOC]
 
@@ -74,15 +77,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/53c84cf9/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 09f6dab..463f393 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,7 +1,10 @@
-title=OpenID AuthenticationHandler             
-type=page
+title=TODO title for openid-authenticationhandler.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: OpenID AuthenticationHandler
 
 [TOC]
 

http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/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 c5a3b2c..15baf15 100644
--- 
a/content/documentation/the-sling-engine/authentication/authentication-framework.md
+++ 
b/content/documentation/the-sling-engine/authentication/authentication-framework.md
@@ -1,16 +1,19 @@
-title=Authentication - Framework               
-type=page
+title=TODO title for authentication-framework.md 
+date=1900-01-01
+type=post
+tags=blog
 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.
 
@@ -45,7 +48,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>
 
 
@@ -64,7 +67,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);
 
 
 
@@ -82,13 +85,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/53c84cf9/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 ebf775e..8af499f 100644
--- 
a/content/documentation/the-sling-engine/authentication/authentication-tasks.md
+++ 
b/content/documentation/the-sling-engine/authentication/authentication-tasks.md
@@ -1,24 +1,27 @@
-title=Authentication - Tasks           
-type=page
+title=TODO title for authentication-tasks.md 
+date=1900-01-01
+type=post
+tags=blog
 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/53c84cf9/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 fd88767..703b243 100644
--- a/content/documentation/the-sling-engine/default-mapping-and-rendering.md
+++ b/content/documentation/the-sling-engine/default-mapping-and-rendering.md
@@ -1,7 +1,10 @@
-title=Default Mapping and Rendering            
-type=page
+title=TODO title for default-mapping-and-rendering.md 
+date=1900-01-01
+type=post
+tags=blog
 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/53c84cf9/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 7a9b465..1c0188f 100644
--- a/content/documentation/the-sling-engine/dispatching-requests.md
+++ b/content/documentation/the-sling-engine/dispatching-requests.md
@@ -1,7 +1,10 @@
-title=Dispatching Requests             
-type=page
+title=TODO title for dispatching-requests.md 
+date=1900-01-01
+type=post
+tags=blog
 status=published
 ~~~~~~
+Title: Dispatching Requests
 
 ## Main process
 
@@ -15,23 +18,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/53c84cf9/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 74e65b9..3e25dee 100644
--- a/content/documentation/the-sling-engine/errorhandling.md
+++ b/content/documentation/the-sling-engine/errorhandling.md
@@ -1,7 +1,10 @@
-title=Errorhandling            
-type=page
+title=TODO title for errorhandling.md 
+date=1900-01-01
+type=post
+tags=blog
 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.
 
@@ -9,7 +12,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]
@@ -21,12 +24,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
@@ -35,13 +38,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
@@ -57,13 +60,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/53c84cf9/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 180368c..38f9dd6 100644
--- a/content/documentation/the-sling-engine/featureflags.md
+++ b/content/documentation/the-sling-engine/featureflags.md
@@ -1,19 +1,22 @@
-title=Feature Flags            
-type=page
+title=TODO title for featureflags.md 
+date=1900-01-01
+type=post
+tags=blog
 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

Reply via email to