You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2017/06/19 12:41:30 UTC
[24/53] sling-site git commit: asf-site branch created for published
content
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/context-aware-configuration/context-aware-configuration.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/context-aware-configuration/context-aware-configuration.md b/content/documentation/bundles/context-aware-configuration/context-aware-configuration.md
deleted file mode 100644
index a092cfa..0000000
--- a/content/documentation/bundles/context-aware-configuration/context-aware-configuration.md
+++ /dev/null
@@ -1,255 +0,0 @@
-title=Apache Sling Context-Aware Configuration
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-# About
-
-These bundles provide a service API that can be used to get context-aware configurations. Context-aware configurations are configurations that are related to a content resource or a resource tree, e.g. a web site or a tenant site.
-
-Here is an example how your content structure may look like:
-
-
-
-The application needs different configuration for different sites, regions and tenants = different contexts. Some parameters may be shared, so inheritance for nested contexts and from global fallback values is supported as well. You have full control which content subtrees are the contexts in your application, the structure above is only an example.
-
-Using the Context-Aware Configuration Java API you can get the matching configuration for each content resource without caring where it is stored or how the inheritance works.
-
-
-# Java API
-
-To get and use configurations, the Java API must be used. Any using code must not make any assumptions on how the context-aware configurations are searched or stored!
-
-The Java API consists of two parts:
-
-- Context-Aware Resources: 'Low-level' API for accessing configuration resources (which can be anything, e.g. workflow definitions)
-- Context-Aware Configurations: 'High-level' API for accessing configuration data (key/value pairs)
-
-In most cases you will use only the 'High-level' API for getting context-aware configurations.
-
-
-## Context-Aware Resources
-
-The base concept are context-aware resources: for a given content resource, a named configuration resource can be get.
-The service for getting the configuration resources is called the ConfigurationResourceResolver. This service has two methods:
-
-- getting a named configuration resource
-- getting all child resources of a named configuration resource.
-
-For example to get a configuration resource for a content resource at /content/mysite/page1, you would get a reference to the OSGi service
-`org.apache.sling.caconfig.resource.ConfigurationResourceResolver` and write:
-
-#!java
-Resource contentResource = resourceResolver.getResource("/content/mysite/page1");
-
-Resource configResource = configurationResourceResolver.getResource(contentResource, "my-bucket", "my-config");
-
-Or if you have several configuration resources of the same type and you need all of them:
-
-#!java
-Collection<Resource> configResources = configurationResourceResolver.getResourceCollection(contentResource, "my-bucket", "my-config");
-
-The ConfigurationResourceResolver has a concept of "buckets" (2nd parameter in the method signatures) that allows to separate different types of configuration resources into different resource hierarchies, so you have a separate "namespaces" for the named configuration resources. For example one bucket for workflow definitions, one bucket for template definitions, one for key/value-pairs.
-
-The configuration name (3rd parameter) defines which configuration you are interested in. The name can be a relative path as well (e.g. `"sub1/my-config"`).
-
-
-## Context-Aware Configurations
-
-While context-aware resources give you pure resources and your application code can decide what to do with it,
-the most common use case is some configuration. A configuration is usually described by an annotation class
-(like Declarative Services does for component configurations). These are typed configuration objects
-and the context-aware configuration support automatically converts resources into the wanted configuration type.
-
-Context-aware configurations are built on top of context-aware resources. The same concept is used: configurations are
-named and the service to get them is the ConfigurationResolver. You can get a reference to the OSGi service
-`org.apache.sling.caconfig.ConfigurationResolver` - it has a single method to get a ConfigurationBuilder.
-Alternatively you can directly adapt your content resource directly to the ConfigurationBuilder interface and get the configuration:
-
-#!java
-Resource contentResource = resourceResolver.getResource("/content/mysite/page1");
-
-MyConfig config = contentResource.adaptTo(ConfigurationBuilder.class).as(MyConfig.class);
-
-Or if you want to get a list of configurations:
-
-#!java
-Collection<MyConfig> configs = contentResource.adaptTo(ConfigurationBuilder.class).asCollection(MyConfig.class);
-
-The ConfigurationBuilder also supports getting the configurations as ValueMap or by adapting the configuration resources e.g. to a Sling Model. In this case you have to specify a configuration name which is otherwise derived automatically from the annotation class.
-
-Internally the ConfigurationResolver used the ConfigurationResourceResolver to get the configuration resources. It uses always the bucket name `sling:configs`.
-
-
-# Contexts and configuration references
-
-When you use the [Default Implementation][default-impl] contexts in the content resource hierarchy is defined by setting `sling:configRef` properties. Each resource that has a `sling:configRef` property set defines the root resource of a context, the whole subtree is the context. Within the subtree further nested contexts can be defined. The property contains a resource path pointing to a resource below `/conf`. This is the configuration reference.
-
-Example:
-
-
-
-If you define nested contexts or use a deeper hierarchy of resourced in `/conf` the inheritance rules are applied. Additionally it is possible to define default values as fallback if no configuration resource exists yet in `/conf`. See [Default Implementation][default-impl] for details.
-
-
-# Describe configurations via annotation classes
-
-You need an annotation class for each configuration you want to read via the ConfigurationBuilder. The annotation classes may be provided by
-the applications/libraries you use, or you can define your own annotation classes for your application.
-
-The annotation class may look like this:
-
-#!java
-@Configuration(label="My Configuration", description="Describe me")
-public @interface MyConfig {
-
-@Property(label="Parameter #1", description="Describe me")
-String param1();
-
-@Property(label="Parameter with Default value", description="Describe me")
-String paramWithDefault() default "defValue";
-
-@Property(label="Integer parameter", description="Describe me")
-int intParam();
-
-}
-
-The `@Configuration` annotation is mandatory. All properties on the `@Configuration` annotation and the `@Property` annotations are optional - they provide additional metadata for tooling e.g. configuration editors.
-
-By default the annotation class name is used as configuration name, which is also the recommended option. If you want to use an arbitrary configuration name you can specify it via a `name` property on the `@Configuration` annotation.
-
-You may specify custom properties (via `property` string array) for the configuration class or each properties. They are not used by the Sling Context-Aware configuration implementation, but may be used by additional tooling to manage the configurations.
-
-If you provide your own configuration annotation classes in your bundle, you have to export them and list all class names in a bundle header named `Sling-ContextAware-Configuration-Classes` - example:
-
-Sling-ContextAware-Configuration-Classes: x.y.z.MyConfig, x.y.z.MyConfig2
-
-To automate this you can use the Context-Aware Configuration bnd plugin (see next chapter).
-
-
-# Accessing configuration from HTL/Sightly templates
-
-Context-Aware configuration contains a Scripting Binding Values provider with automatically registeres a `caconfig` variable in your HTL/Sightly scripts to directly access context-aware configurations. It supports both singleton configurations and configuration lists. Please note that configuration lists are only supported when configuration metadata is present (e.g. via an annotation class).
-
-Example for accessing a property of a singleton configuration (with a config name `x.y.z.ConfigSample`):
-
-#!html
-<dl>
-<dt>stringParam:</dt>
-<dd>${caconfig['x.y.z.ConfigSample'].stringParam}</dd>
-</dl>
-
-Example for accessing a property of a configuration list (with a config name `x.y.z.ConfigSampleList`):
-
-#!html
-<ul data-sly-list.item="${caconfig['x.y.z.ConfigSampleList']}">
-<li>stringParam: ${item.stringParam}</li>
-</ul>
-
-If you want to access nested configurations you have to use a slash "/" as separator in the property name. Example:
-
-#!html
-${caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']}
-
-
-# Context-Aware Configuration bnd plugin
-
-A [bnd](http://bnd.bndtools.org/) plugin is provided that scans the classpath of a bundle Maven project at build time and automatically generates a `Sling-ContextAware-Configuration-Classes` bundle header for all annotation classes annotated with `@Configuration`. It can be used by both [maven-bundle-plugin](http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html) and [bnd-maven-plugin](https://github.com/bndtools/bnd/tree/master/maven), as both use the bnd library internally.
-
-Example configuration:
-
-#!xml
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-bundle-plugin</artifactId>
-<extensions>true</extensions>
-<configuration>
-<instructions>
-<!-- Generate bundle header containing all configuration annotation classes -->
-<_plugin>org.apache.sling.caconfig.bndplugin.ConfigurationClassScannerPlugin</_plugin>
-</instructions>
-</configuration>
-<dependencies>
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.caconfig.bnd-plugin</artifactId>
-<version>1.0.2</version>
-</dependency>
-</dependencies>
-</plugin>
-
-
-# Unit Tests with Context-Aware Configuration
-
-When your code depends on Sling Context-Aware Configuration and you want to write Sling Mocks-based unit tests running against the Context-Aware configuration implementation you have to register the proper OSGi services to use them. To make this easier, a "Apache Sling Context-Aware Configuration Mock Plugin" is provided which does this job for you.
-
-Example for setting up the unit test context rule:
-
-#!java
-import static org.apache.sling.testing.mock.caconfig.ContextPlugins.CACONFIG;
-
-public class MyTest {
-
-@Rule
-public SlingContext context = new SlingContextBuilder().plugin(CACONFIG).build();
-
-@Before
-public void setUp() {
-// register configuration annotation class
-MockContextAwareConfig.registerAnnotationClasses(context, SimpleConfig.class);
-}
-...
-
-In you project define a test dependency (additionally the sling-mock dependency is required):
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.caconfig-mock-plugin</artifactId>
-<scope>test</scope>
-</dependency>
-
-Full example: [Apache Sling Context-Aware Configuration Mock Plugin Test](https://github.com/apache/sling/blob/trunk/testing/mocks/caconfig-mock-plugin/src/test/java/org/apache/sling/testing/mock/caconfig/ContextPluginsTest.java)
-
-
-# Customizing the configuration lookup
-
-The Context-Aware Configuration implementation provides a set of Service Provider Interfaces (SPI) that allows you to overlay, enhance or replace the default implementation and adapt it to your needs.
-
-See [SPI][spi] for details.
-
-You can also override specific context-aware configuration within an instance - see [Override][override] for details.
-
-
-# Web Console plugins
-
-The Context-Aware Configuration implementation provides two extension to the Felix Web Console:
-
-- A plugin "Sling / Context-Aware Configuration" that allows to test configuration resolution and prints outs all metadata. This is helpful debugging the resolution and collection and property inheritance. For each resource and property value the the real source resource path is listed.
-- A inventory printer "Sling Context-Aware Configuration" which lists all SPI implementations that are deployed, and additionally prints out all configuration metadata and override strings
-
-To use the web console plugin you need to configure a "Service User" mapping for the bundle `org.apache.sling.caconfig.impl` to a system user which has read access to all context and configuration resources. By default this should be `/content`, `/conf`, `/apps/conf` and `/libs/conf`.
-
-
-# Management API
-
-The Context-Aware Configuration Implementation Bundle provides a Management API which allows to read and write configuration data. It supports only Context-Aware configurations, not context-aware resources. It should not be used directly in applications, but is intended to provide an API for editor GUIs and other tools which allow to manage configurations.
-
-The main entry point is the OSGi service `org.apache.sling.caconfig.management.ConfigurationManager`. It allows to get, write or delete singleton configurations and configuration lists. Configuration data is returned using `ConfigurationData` and `ConfigurationCollectionData` objects which also provide access to additional metadata about the resolving process and inheritance/override status of each property. Internally the configuration manager uses the [SPI][spi] implementation to resolve and write the configuration data.
-
-Whenever configuration data is read or written from the configuration resources a filtering of property names is applied to make sure "system properties" like `jcr:primaryType` or `jcr:created` are not returned as part of the configuration data. A list of regular expressions for this filtering can be configured via the "Apache Sling Context-Aware Configuration Management Settings" OSGi configuration. The configuration is accessible to custom persistence implementations via the `org.apache.sling.caconfig.management.ConfigurationManagementSettings` OSGi service. By default all properties in the `jcr:` namespace are filtered out.
-
-
-# References
-
-* [Context-Aware Configuration - Default Implementation][default-impl]
-* [Context-Aware Configuration - SPI][spi]
-* [Context-Aware Configuration - Override][override]
-* [Sling Context-Aware Configuration - Talk from adaptTo() 2016](https://adapt.to/2016/en/schedule/sling-context-aware-configuration.html)
-
-
-[default-impl]: http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-default-implementation.html
-[spi]: http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-spi.html
-[override]: http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/context-aware-configuration/illustration-sources.pptx
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/context-aware-configuration/illustration-sources.pptx b/content/documentation/bundles/context-aware-configuration/illustration-sources.pptx
deleted file mode 100644
index 324604e..0000000
Binary files a/content/documentation/bundles/context-aware-configuration/illustration-sources.pptx and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/context-aware-configuration/resource-inheritance.png
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/context-aware-configuration/resource-inheritance.png b/content/documentation/bundles/context-aware-configuration/resource-inheritance.png
deleted file mode 100644
index 89cc9f4..0000000
Binary files a/content/documentation/bundles/context-aware-configuration/resource-inheritance.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/datasource-providers.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/datasource-providers.md b/content/documentation/bundles/datasource-providers.md
deleted file mode 100644
index 64942c8..0000000
--- a/content/documentation/bundles/datasource-providers.md
+++ /dev/null
@@ -1,123 +0,0 @@
-title=DataSource Provider
-type=page
-status=published
-~~~~~~
-
-DataSource provider bundle supports creation of `DataSource` instance and registering them with
-the OSGi service registry. Application using the DataSource just obtains it from OSGi while
-an administrator can configure the DataSource via Felix WebConsole configuration UI.
-
-[TOC]
-
-## Pooled Connection DataSource Provider
-
-This bundle enables creating and configuring JDBC DataSource in OSGi environment based on
-OSGi configuration. It uses [Tomcat JDBC Pool][1] as the JDBC Connection Pool provider.
-
-1. Supports configuring the DataSource based on OSGi config with rich metatype
-2. Supports deploying of JDBC Driver as independent bundles and not as fragment
-3. Exposes the DataSource stats as JMX MBean
-4. Supports updating of DataSource connection pool properties at runtime without restart
-
-### Driver Loading
-
-Loading of JDBC driver is tricky on OSGi env. Mostly one has to attach the Driver bundle as a
-fragment bundle to the code which creates the JDBC Connection.
-
-With JDBC 4 onwards the Driver class can be loaded via Java SE Service Provider mechanism (SPM)
-JDBC 4.0 drivers must include the file META-INF/services/java.sql.Driver. This file contains
-the name of the JDBC driver's implementation of java.sql.Driver. For example, to load the JDBC
-driver to connect to a Apache Derby database, the META-INF/services/java.sql.Driver file would
-contain the following entry:
-
-org.apache.derby.jdbc.EmbeddedDriver
-
-Sling DataSource Provider bundles maintains a `DriverRegistry` which contains mapping of Driver
-bundle to Driver class supported by it. With this feature there is no need to wrap the Driver
-bundle as fragment to DataSource provider bundle
-
-
-### Configuration
-
-1. Install the current bundle
-2. Install the JDBC Driver bundle
-3. Configure the DataSource from OSGi config for PID `org.apache.sling.datasource.DataSourceFactory`
-
-If Felix WebConsole is used then you can configure it via Configuration UI at
-http://localhost:8080/system/console/configMgr/org.apache.sling.datasource.DataSourceFactory
-
-
-
-Using the config ui above one can directly configure most of the properties as explained in [Tomcat Docs][1]
-
-### Convert Driver jars to Bundle
-
-Most of the JDBC driver jars have the required OSGi headers and can be directly deployed to OSGi container
-as bundles. However some of the drivers e.g. Postgres are not having such headers and hence need to be
-converted to OSGi bundles. For them we can use the [Bnd Wrap][2] command.
-
-For example to convert the Postgres driver jar follow the steps below
-
-$ wget https://github.com/bndtools/bnd/releases/download/2.3.0.REL/biz.aQute.bnd-2.3.0.jar -O bnd.jar
-$ wget http://jdbc.postgresql.org/download/postgresql-9.3-1101.jdbc41.jar
-$ cat > bnd.bnd <<EOT
-Bundle-Version: 9.3.1101
-Bundle-SymbolicName: org.postgresql
-Export-Package: org.postgresql
-Include-Resource: @postgresql-9.3-1101.jdbc41.jar
-EOT
-$ java -jar bnd.jar bnd.bnd
-
-In the steps above we
-
-1. Download the bnd jar and postgres driver jar
-2. Create a bnd file with required instructions.
-3. Execute the bnd command
-4. Resulting bundle is present in `org.postgresql-9.3.1101.jar`
-
-## JNDI DataSource
-
-While running in Application Server the DataSource instance might be managed by app server and registered with
-JNDI. To enable lookup of DataSource instance from JNDI you can configure `JNDIDataSourceFactory`
-
-1. Configure the DataSource from OSGi config for PID `org.apache.sling.datasource.JNDIDataSourceFactory`
-2. Provide the JNDI name to lookup from and other details
-
-If Felix WebConsole is used then you can configure it via Configuration UI at
-http://localhost:8080/system/console/configMgr/org.apache.sling.datasource.JNDIDataSourceFactory
-
-Once configured `JNDIDataSourceFactory` would lookup the DataSource instance and register it with OSGi
-ServiceRegistry
-
-## Usage
-
-Once the required configuration is done the `DataSource` would be registered as part of the OSGi Service Registry
-The service is registered with service property `datasource.name` whose value is the name of datasource provided in
-OSGi config.
-
-Following snippet demonstrates accessing the DataSource named `foo` via DS annotation
-
-::java
-import javax.sql.DataSource;
-import org.apache.felix.scr.annotations.Reference;
-
-public class DSExample {
-
-@Reference(target = "(&(objectclass=javax.sql.DataSource)(datasource.name=foo))")
-private DataSource dataSource;
-}
-
-## Installation
-
-Download the bundle from [here][3] or use following Maven dependency
-
-::xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.datasource</artifactId>
-<version>1.0.0</version>
-</dependency>
-
-[1]: http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
-[2]: http://bnd.bndtools.org/chapters/390-wrapping.html
-[3]: http://sling.apache.org/downloads.cgi
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/discovery-api-and-impl.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/discovery-api-and-impl.md b/content/documentation/bundles/discovery-api-and-impl.md
deleted file mode 100644
index 10abaf9..0000000
--- a/content/documentation/bundles/discovery-api-and-impl.md
+++ /dev/null
@@ -1,413 +0,0 @@
-title=Discovery API and its implementations
-type=page
-status=published
-~~~~~~
-
-In many situations a particular Sling-based deployment consists of several Sling instances:
-typically a number of instances would form a `cluster` that share a common content repository -
-in other situations, or additionally, instances might be loosely coupled, each with their own repository.
-
-The `discovery-api` bundle introduces an abstraction for such scenarios called `topology`. It provides
-access to the current topology, allows to be informed of any changes in the topology (such as joining or leaving
-instances) and contains a simple property exchange mechanism, e.g. to allow building communication services on top of it.
-
-[TOC]
-
-## Discovery Entities
-
-The Discovery API defines the following entities
-
-### Instance, InstanceDescription
-
-A Sling instance running in one VM is represented in the discovery API by an `InstanceDescription`:
-
-* it represents one Sling instance
-* it has thus a unique Sling ID
-* it has a flag that marks if it is leader in a cluster (more details below)
-* plus it has properties (which can be provided via `PropertyProviders`)
-
-### Cluster, ClusterView
-
-Multiple instances that are connected to the same underlying repository are commonly referred to as a 'Cluster'. The reasoning behind this terminology being that they access the same data and can thus deliver or modify the same data.
-
-In the discovery API this cluster concept is represented via a `ClusterView` object. A 'view' because it is a momentary snapshot of the cluster and only contains instances that are currently alive. It's features are:
-
-* each cluster has a stable leader. Stable meaning it won't change unless that leader crashes.
-* it has an ordered, stable list of instances that are part of it, thus currently alive. the relative order of instances in this list is stable, meaning that it only stays or moves up one position if an instance listed 'above' crashes - a newly started instance will always be added at the end of this list.
-* plus it has a unique id that is persistent across restarts
-
-### Topology, TopologyView
-
-The topology - or more precisely the `TopologyView` - represents a snapshot (`view`) of a number of loosely coupled Sling instances (`InstanceDescription`)
-and clusters (`ClusterView`) of a particular deployment. A cluster can consist of one or more instances. Each instance
-is always part of a cluster (even if the cluster consists of only one instance). The features are:
-
-* only one: it has a list of clusters
-
-There are no further assumption made on the structure of a topology.
-
-If different clusters in the topology should represent different 'types of clusters' (eg a publish or an author cluster),
-then that is not explicitly handled by the discovery API. Instead, applications can define properties on each instance
-that model such cluster types or other aspects.
-
-## Cluster Leader and Instance Ordering
-
-As mentioned the discovery API introduces support for a `cluster leader`: within each cluster, the API guarantees that one and only one
-instance is leader at any time. That leader is guaranteed to be `stable`, ie as long as it stays alive and is visible
-by other instances of the same cluster, it will stay leader. As soon as it leaves the cluster (or the corresponding
-implementation bundle is deactivated), another instance in that cluster is elected leader. The leader can be used to
-deal with work that must be guaranteed to only execute on one (but any) instance in the cluster.
-
-Additionally each cluster (`ClusterView`) orders its instances in a stable list: each newly joined instances is added
-at the end of the list and retains its order in the list as long as it doesn't leave the cluster. This can be used
-to distribute "singleton" work amongst the cluster to more than just the leader.
-
-## Topology Changes
-
-The `DiscoveryService` provides access to the currently valid `TopologyView`. Additionally, applications can
-register a `TopologyEventListener` and thus be informed about any changes in the topology. Whenever the discovery
-service detects that an instance is no longer responding or has newly joined, or a new leader has been elected,
-it sends a `TOPOLOGY_CHANGING` event, starts
-settling the change within the topology (i.e. making sure everybody else in the topology agrees with the change) and finally
-sends a `TOPOLOGY_CHANGED` event with the new topology.
-
-Additionally, when "only" properties have changed, a `PROPERTIES_CHANGED` event is sent.
-
-Note that the detection of topology (or properties) changes will incur a delay which is implementation dependent.
-
-The following is an example of a listener. Note that the binding is done automatically by OSGi, as soon as a
-`TopologyEventListener` is registered.
-
-import org.apache.felix.scr.annotations.Component;
-import org.apache.felix.scr.annotations.Service;
-import org.apache.sling.discovery.TopologyEvent;
-import org.apache.sling.discovery.TopologyEventListener;
-
-@Component
-@Service(value = { TopologyEventListener.class })
-public class MyTopologyEventListener implements TopologyEventListener {
-
-public void handleTopologyEvent(final TopologyEvent event) {
-// your code here
-}
-
-}
-
-
-## Properties
-
-The discovery API not only lists all clusters and instances that are part of a topology but also provides a simple
-mechanism for announcing properties of each instance to the topology, via the `PropertyProvider` service interface.
-
-Typical use cases for this are announcements of endpoint URLs or ports such that applications can communicate to other
-instances in the topology.
-
-Note that the properties mechanism is not meant be used as a messaging tool: both from an API point of view and
-the implementation of it are not optimized for frequent changes and its use for messaging is discouraged. It is only
-meant to be used to announce configuration information for accessing proper messaging services.
-
-The following is an example of a `PropertyProvider` that provides `sample.value1` and `sample.value2` properties:
-
-import org.apache.felix.scr.annotations.Component;
-import org.apache.felix.scr.annotations.Service;
-import org.apache.sling.discovery.PropertyProvider;
-
-@Component
-@Service(value = { PropertyProvider.class })
-@Property(name = PropertyProvider.PROPERTY_PROPERTIES,
-value = {"sample.value1", "sample.value2" })
-public class SamplePropertyProvider implements PropertyProvider {
-
-public String getProperty(final String name) {
-if ("sample.value1".equals(name)) {
-return "foo";
-} else if ("sample.value2".equals(name)) {
-return "bar";
-} else {
-return null;
-}
-}
-}
-
-## Deployment and configuration
-
-The discovery API makes no assumptions as to how the instances and clusters discover each other. This is entirely
-up to the implementations. Some might choose automatic discovery within a LAN using IP multicast, others
-might choose explicit configuration via a central service etc.
-
-## discovery.impl: Resource-based, OOTB Implementation
-
-The `discovery.impl` bundle is a resource-based, out of the box implementation of the `discovery.api` using standard Sling.
-
-The discovery within a cluster is done by writing heartbeat information into the (common) repository (there's no other form
-of communication within a cluster). The establishment of a
-clusterview is done by analyzing these heartbeats, initiating a voting within the cluster (such that each instance can agree
-that it sees the same number of instances) and by concluding the voting by promoting it as the new "established" view.
-
-The discovery of instances and clusters outside the local cluster requires explicit configuration of what is termed
-'topology connectors', which are HTTP PUTs (see below).
-
-### Location in Repository
-
-Administrative note: All the information about the topology is stored at the following location in the repository:
-
-/var/discovery/impl
-
-#### /var/discovery/impl/clusterInstances/<slingId>
-
-Each instance has its own node under `clusterInstances/` where it stores:
-
-* `lastHeartbeat`: property, which marks the instance as alive for another `heartbeatTimeout`
-* `leaderElectionId`: an id which is used to determine the leader: the instance with the lowest such leaderElectionId is the leader.
-Therefore this id is crucial to implement stable leader and ordering. The id contains a prefix (to account for a crx2 edge case
-where jobs might want to be executed on slave rather than on master), followed by the bundle activate time (to honour stability)
-and ultimately by the slingId (to have a discriminator should there be multiple instances started at the same time)
-* `runtimeId`: a plain, random UUID that is created fresh upon bundle activation. It is used to detect situations where
-multiple instances have the same slingId and thus write into the same `/var/discovery/impl/clusterInstances/<slingId>` node.
-* `slingHomePath` and `endpoints`: these are used for logging purpose only
-
-Additionally, there are two sub-nodes:
-
-* `announcements`: this contains announcements of topology connector peers (also see below). An announcement is a json-encoded
-representation of the sub-tree that the connector peer is aware of and is thereby announcing to this instance. Announcements
-are sent in both directions of a topology connector. Discovery.impl takes care of filtering out duplicate instances should
-the structure of topology connectors, and thus these announcements overlap (which is legal)
-* `properties`: contains all properties as specified by registered `PropertyProvider`
-
-#### /var/discovery/impl/establishedView
-
-This contains the currently valid, agreed/voted upon cluster view that lists all alive instances:
-
-* the name of the node directly under `establishedView` is a unique id of the current incarnation of the cluster view -
-thus changes whenever an instance joins or leaves or there is a new voting for another reason.
-** `clusterId` : name of the persistent identifier of this cluster. As this is propagated from cluster view to cluster view
-it stays unchanged forever.
-** `leaderElectionId`: the leaderElectionId that was winning, ie that was lowest
-** `leaderId`: the slingId of the instance that is leader of this cluster view
-* `members`: just an intermediate node containing all alive instances as child nodes
-* child node of `members`: each child represents a particular alive node (with the name being the slingId) and contains
-the following properties:
-** `leaderElectionId`: the id that will be used to determine the leader - this value is copied from the corresponding
-`/var/discovery/impl/clusterInstances/<slingId>`
-** `initiator`: this marks the instance that originally created this voting
-** `vote`: represents this instance's vote, which is true for a voting that got promoted to established view
-
-#### /var/discovery/impl/ongoingVotings
-
-This area is used for voting. Each instance can initiate a voting when it realizes that the live instances - denominated
-by those instances that have a not-yet-timed-out heartbeat property - does not match with the `establishedView`.
-
-Once a voting gets a yes vote by all instances it is promoted (moved) under `establishedView` by the initiating instance.
-Each establishedView was once a voting, thus the structure is the same as described above.
-
-#### /var/discovery/impl/previousView
-
-The instance that promotes its winning voting to `establishedView` first moves what was there before under `previousView`.
-This is purely for debugging and not used anywhere, it just represents a persistet history of previous views of length 1.
-
-### Heartbeats, Voting and Intra-Cluster Discovery
-
-`discovery.impl` uses the fact that all instance of a cluster are connected to the same repository as the
-basis for discovering those instances. It does so by using a heartbeat and voting mechanism:
-
-* each instance periodically stores a 'heartbeat' into the repository in a well-known location.
-This is done by setting a corresponding `lastHeartbeat` property to the current timestamp
-* a 'heartbeat' that has not yet timed out is considered a signal that the instance is alive
-* as soon as a 'heartbeat' is timed out, the assumption is that the corresponding instance is dead/shutdown
-
-To avoid having each instance make it's own, perhaps differing conclusions as to which instance/heartbeat is dead or not,
-there is an explicit, unanimous voting mechanism that agrees upon a list of alive instances. This list of alive
-instances is called cluster view.
-
-* as soon as any instance notices a change in the list of active instances, it is free to calculate a new
-such list and start a voting in the cluster - each voting carries a unique votingId
-* since any instance can do this, you can have concurrent creation of new votings
-* each instance has one 'yes' vote - and if there are multiple concurrent votings the lowest one wins
-* when a voting receives a 'yes' from all instances that it enlists it is considered as 'winning'
-and is promoted to be the new, valid view from now on.
-* a promoted view is stored in `/var/discovery/impl/establishedView` and any change therein is
-passed on in a TopologyEvent to all registered listeners.
-
-### pseudo-network partitioning aka split-brain
-
-`discovery.impl` requires the, eventually consistent, underlying repository to propagate changes within reasonable time:
-in less than the configured heartbeat timeout. If heartbeats for some reason are not becoming visible by peers in
-the cluster within that time, `discovery.impl` will consider that peer instance as dead. At which point it will
-first send a TOPOLOGY_CHANGING event to all listeners to make them aware that something is changing in the topology,
-and then start a new voting. Once the voting concludes a TOPOLOGY_CHANGED event will follow.
-
-Given the voting is happening through the repository as well, one could imagine a situation where the repository delays
-can cause a topology to be "pseudo partitioned" into two or more parts, each one agreeing on a set of instances in that
-sub-cluster (one requirement for such a scenario being that the delays must be asymmetric, ie changes from a subset
-of instances propagate slow, while the remaining changes propagate fast - ie. two different sets of delays in the cluster).
-Such a situation would only last as long as the repository delays are large (larger than
-the heartbeat timeouts). Exact cases where the repository experiences large delays depend of course on the
-repository configuration and deployment details, known cases include for example long running queries, large set
-of changes, large set of commits and long-running session.saves.
-
-The following is an illustration of the impact of large cluster delays:
-
-
-
-In discovery.impl 1.2.2 several improvements have been done to avoid pseudo-network partitioning including the following:
-(see SLING-3432 for more in-depth details)
-
-* SLING-5195 : monitor the HeartbeatHandler for long-running session.saves.
-* SLING-5280 : reduce synchronization for HeartbeatHandler to avoid other threads blocking it
-* SLING-5030 : avoid "isolated mode" and replace it with larger TOPOLOGY_CHANGING phase
-
-All of the above greatly reduce the likelyhood of pseudo-network partitioning with `discovery.impl`, however, as
-also described in SLING-4640, there is still a small time-window in which it cannot be ruled out entirely.
-The successor of discovery.impl, the `discovery.oak` bundle, addresses these concerns to avoid pseudo-network
-partitioning alltogether.
-
-In the context of `discovery.impl` it is therefore paramount that the underlying repository is monitored and optimized
-such that the delays are well under control and do not exceed the configured heartbeat timeout.
-
-### Topology Connectors for Cross-Cluster Discovery
-
-From a discovery API's point of view a cluster consists of all instances that are connected to the same repository.
-The above described built-in mechanism of storing a lastHeartbeat property into the (shared) repository, of voting on changes
-and creating an explicit establishedView results in automatic discovery within a cluster. There is therefore
-no further configuration needed for discovering instances in the same cluster.
-
-However, for discovering multiple clusters such an automatic discovery is not possible and the clusters need
-to be explicitly configured using (cross-cluster) topology connectors:
-
-A topology connector is a periodically issued HTTP PUT that announces the part of the topology known to the
-sending instance to the receiving instance and vica-verca the receiving instance announces its part of the
-topology to the sender in the response of the very same HTTP PUT. This way whatever other clusters are connected
-to sender or receiver will be made known to each other. Such a 'topology announcement' will be valid either until
-the same sender sends the announcement again (which it does periodically) - or until it times out (configurable).
-A topology connector is by definition always between clusters, never within the same cluster. Topology connectors
-can be structured in an arbitrary way (chain, star, tree, etc) with the only important point to note here that
-since changes in the topology propagate through these topology connectors they have a certain delay (namely
-the configured heartbeatInterval per hop).
-
-Topology connectors are configured at [/system/console/configMgr/org.apache.sling.discovery.impl.Config][1].
-They use the same interval and timeout as the repository heartbeats (heartbeatInterval and heartbeatTimeout).
-
-### WebConsole
-
-A Felix WebConsole plugin at [/system/console/topology][2] provides a (read-only) overview of the topology.
-
-### Configuration
-
-The following properties can be configured (at [/system/console/configMgr/org.apache.sling.discovery.impl.Config][1]):
-
-* heartbeatInterval: the time in seconds between two heartbeats (both cluster-internal and for HTTP-connectors). Default
-value is 15 seconds.
-
-* heartbeatTimeout: the time in seconds after which an instance is considered dead if no heartbeat was sent since. Default
-value is 20 seconds.
-
-* topologyConnectorUrls: a list of connector URLs to which this instance should connect to. The list can contain multiple
-instances of the same cluster (for fallback configurations). If the list is empty, no connector will be created.
-The default relative URL is /libs/sling/topology/connector. Note that this URL is accessible without authentication -
-to avoid having to configure administrative username/passwords in all instances. Instead, a whitelist approach is used
-(see next item).
-
-* topologyConnectorWhitelist: As mentioned above, the path /libs/sling/topology/connector does not require authentication.
-To assure that only trusted instances can connect to the topology, its hostname or IP address must be in a whitelist.
-By default this whitelist only contains localhost and 127.0.0.1.
-
-* minEventDelay: To reduce the number of events sent during changes, there is a delay (in seconds) before the event is sent.
-If additional changes happen during this delay, the change will be combined in one event.
-
-* leaderElectionRepositoryDescriptor: this is an advanced parameter. It denotes a repository descriptor that is evaluated
-and taken into account for leader Election: the corresponding value of the descriptor is sorted by first.
-
-* hmacEnabled: If this is true, and sharedKey is set to a value on all Sling instances within the same topology, then messages are
-validates using a signature of the content of the message based on the shared key. The signature and the digest of the content
-appear as http headers. When hmac message validation is enabled, whitelisting is disabled. This use useful where the topology
-messages are transported through multiple reverse proxy layers or the topology is dynamic. The Hmac algorithm in use is HmacSHA256.
-The JVM is expected to have a provider implementing this algorithm (The Standard JDKs do).
-
-* sharedKey: If hmacEnabled is true, this must be set to a secret value, shared amongst all Sling instances that are members of the
-same topology.
-
-* enableEncryption: If hmacEnabled is true, and sharedKey is set, setting this to true will encrypt the body of the message using 128 Bit
-AES encryption. The encryption key is derived from the sharedKey using a 9 byte random salt, giving 2^^72 potential salt values.
-
-* hmacSharedKeyTTL: The key used for the signatures is derived from the shared key. Each derived key has a lifetime before the next key
-is generated. This parameter sets the lifetime of each key in ms. The default is 4h. Messages sent using old keys will remain valid for
-2x the TTL, after which time the message will be ignored.
-
-
-[1]: http://localhost:8888/system/console/configMgr/org.apache.sling.discovery.impl.Config
-[2]: http://localhost:8888/system/console/topology
-
-
-## discovery.oak: Oak-based, OOTB-implementation
-
-When running discovery.impl ontop of an eventually consistent repository (such as documentMK of oak), the heartbeat mechanism
-becomes unreliable. The eventual-ness of the repository has an inherent problem in that it doesn't guarantee by when a change
-initiated from instance A is visible by instance B. And when there are no hard guarantees, it becomes impossible to choose
-a `heartbeatTimeout` that works for all eventualities.
-
-Therefore it becomes necessary to be able to store heartbeats in a (low-level) location that provides higher consistency (than eventualness).
-Such a 'low-level location' is the DocumentStore of oak (which is an internal API of the DocumentNodeStore). Turns out that
-the DocumentNodeStore already has a heartbeat-like concept called leases. Those can be re-used for discovery to fulfill the same
-aspect as heartbeats do: indicate alive instances. This can further be combined with
-an explicit materialization of a "cluster view" in the DocumentStore so that all instances agree and refer to the same
-view without the actual need for voting (this is possible since the DocumentStore allows to do conditional updates).
-
-### Jackrabbit Oak's discovery-lite
-
-All of the above mentioned features have been implemented in so-called 'discovery-lite': Discovery-lite is a simplified
-version of discovery on the oak level. Other than the discovery API it only provides one thing, and that's the
-clusterview-json:
-
-#### 'oak.discoverylite.clusterview'
-
-The discovery-lite descriptor `oak.discoverylite.clusterview` is a shrink-wrapped json-formatted object representing
-the current state of the cluster. It contains the following:
-
-* `active`: a list of active nodes in the documentNodeStore cluster
-* `deactivating`: a list of nodes that are in the process of being deactivated
-* `inactive`: a list of nodes that are inactive
-* `me`: the id (number) of the local instance (which is always part of the active nodes)
-* `id`: the id (unique, persistent) of the cluster (which thus survives node/cluster restarts)
-* `seq`: a sequence number that is incremented upon each change in this descriptor (to be able to identify a change even if
-the other values are unchanged) and shared amongst all instances in the cluster, ie all instances see the same sequence number.
-This number can thus be used by upper layers to identify this particular incarnation of clusterview.
-* `final`: when this flag is `false` it indicates that the sequence number has changed (as well as eg `active` and `inactive`),
-but that the local instance has not yet fully processed this changed on a low-level. I.e. it marks that the local
-instance has not yet read the entire back-log of another, deactivating instance. Thus when `final==false`, the upper layers
-should wait until `final==true`, at which point they know oak has finished processing an instance crashing/shutting down.
-
-#### Accessing discovery-lite
-
-The `oak.discoverylite.clusterview` descriptor is exposed as a JCR repository descriptor and can be accessed like so:
-
-getRepository().getDescriptor("oak.discoverylite.clusterview")
-
-which will return the json-formatted clusterview as described above.
-
-Note however, that this API is not meant to be a public, stable API and changes will be done without prior notice.
-It is merely an internal information exposed by oak and not standardized nor guaranteed to remain supported or unchanged!
-
-### Sling's discovery.oak
-
-discovery.oak is a implementation of the discovery API that now makes use of this new discovery-lite descriptor in oak.
-It basically delegates the detection of the instances in the local cluster to discovery-lite. To do so, it periodically
-reads this descriptor (which is designed to be read at a high-frequency without problems) and triggers `TopologyEvents`
-when this descriptor changes.
-
-The advantage of using discovery-lite (which uses oak leases) instead of writing heartbeats into the repository
-is that discovery.oak thus becomes independent of the speed/latency that the repository can produce under high load.
-The discovery-lite should be entirley resilient to high load, thus is discovery.oak.
-
-Additionally, it reuses functionality from discovery.impl, such as the way properties (from `PropertyProviders`) or
-cross-cluster topology announcements (via topology connectors) are handled.
-
-In order to do this, the discovery.impl bundle has been refactored as follows:
-
-#### discovery.commons
-
-This is a bundle usable by any implementation of discovery and contains very basic, implementation-independent functionality
-
-#### discovery.base
-
-This is the base bundle solely used by discovery.impl and discovery.oak and contains exactly the mentioned
-properties and announcement handling.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/discovery-impl-split-brain.png
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/discovery-impl-split-brain.png b/content/documentation/bundles/discovery-impl-split-brain.png
deleted file mode 100644
index d14c7fe..0000000
Binary files a/content/documentation/bundles/discovery-impl-split-brain.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/dynamic-includes.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/dynamic-includes.md b/content/documentation/bundles/dynamic-includes.md
deleted file mode 100644
index 54a4b77..0000000
--- a/content/documentation/bundles/dynamic-includes.md
+++ /dev/null
@@ -1,27 +0,0 @@
-title=Apache Sling Dynamic Include
-type=page
-status=published
-~~~~~~
-Notice: Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-.
-http://www.apache.org/licenses/LICENSE-2.0
-.
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
-
-Sling Dynamic Include (org.apache.sling.dynamic-include)
-========================================================
-For now the Sling Dynamic Include documentation can be found
-[in the Sling codebase](https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/sling-dynamic-include/README.md)
-or
-[on our GitHub mirror](https://github.com/apache/sling/tree/trunk/contrib/extensions/sling-dynamic-include) if that's in sync.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/file-installer-provider.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/file-installer-provider.md b/content/documentation/bundles/file-installer-provider.md
deleted file mode 100644
index 9332f83..0000000
--- a/content/documentation/bundles/file-installer-provider.md
+++ /dev/null
@@ -1,42 +0,0 @@
-title=File Installer Provider
-type=page
-status=published
-~~~~~~
-
-The file installer provider scans configured directories and provides the found artifacts (files) to the [OSGI installer](/documentation/bundles/osgi-installer.html). The functionality is very similar to Apache Felix FileInstall, with the major difference that this service implements just the task of scanning a file directory. All the management logic is implemented in the OSGi installer and support of various artifact types like bundles, configurations or custom formats is implemented by plugins for the OSGi installer.
-
-
-## Setup
-
-The file installer can be configured with these framework (system) properties:
-
-|Property|Default|Description|
-|--|--|--|
-|`sling.fileinstall.dir`| |The name/path of the directories to watch. Several directories can be specified by using a comma separated list. Each directory might have arbitrarily many sub directories (even nested ones) which may contain the artifacts|
-|`sling.fileinstall.interval`|5000 ms|Number of milliseconds between 2 polls of the directory|
-|`sling.fileinstall.writeback`|true|If the file provider supports writeback of changed artifacts, e.g. if a configuration is changed through Config Admin the change is written back to the file system.|
-
-## Bundles
-
-Bundles are supported by the OSGi installer. If a bundle jar is added to a scanned directory, this bundle is installed. If the file is updated/changed, the bundle is updated. If the file is removed, the bundle gets removed.
-Of course, these are the simple rules. The actual action depends by the overall state of the system and is controlled by the OSGi installer. For example if already the same bundle with a higher version is installed, when a bundle is dropped into the install folder, the OSGi installer will perform no operation.
-
-Start levels are supported as well by creating a directory with the name of the start level within the scan directory and putting the bundles within this directory. For example, if the `install` folder is scanned, the bundle `install/3/mybundle.jar` will be installed with start level 3. Without such a directory the default start level is used.
-
-## Configurations
-
-Configurations are handled by the [Configuration Installer Factory](/documentation/bundles/configuration-installer-factory.html). The different formats are described there.
-
-## Custom Artifacts
-
-Custom artifacts are handled by the OSGi installer depending on the installed plugins. Have a look at the OSGi installer and its plugins for more information.
-
-## Runmode Support
-
-The file installer supports run modes for installing artifacts (added with [SLING-4478](https://issues.apache.org/jira/browse/SLING-4478)). Within the scanned directory, a folder prefixed with "install." and followed by one or more run modes (separated by ".") will only be considered if all the respective run modes are active. For example artifacts below a folder named `install.a1.dev` are only taken into account if the run modes `a1` and `dev` are both active.
-
-You can even combine start level and run mode support. Just pay attention that the run mode foldername must be set on a direct child folder of `sling.fileinstall.dir` while the start level must be set directly on the parent folder of the artifact you want to install. E.g. `<sling.fileinstall.dir>/install.a1.dev/3/mybundle.jar` will only be considered if both run modes `a1` and `dev` are set. If this is the case then the according artifact will be installed in start level 3.
-
-# Project Info
-
-* File installer provider ([org.apache.sling.installer.provider.file](http://svn.apache.org/repos/asf/sling/trunk/installer/providers/file))
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/internationalization-support-i18n.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/internationalization-support-i18n.md b/content/documentation/bundles/internationalization-support-i18n.md
deleted file mode 100644
index 49961ca..0000000
--- a/content/documentation/bundles/internationalization-support-i18n.md
+++ /dev/null
@@ -1,177 +0,0 @@
-title=Internationalization Support (i18n)
-type=page
-status=published
-~~~~~~
-
-Internationalization support in Sling consists of four methods in the `SlingHttpServletRequest` interface:
-
-* `getLocale()` -- Returns the primary `Locale` for the current request. This method is inherited from the `javax.servlet.ServletRequest` interface.
-* `getLocales()` -- Returns the `Locale` instances for the current request. This method is inherited from the `javax.servlet.ServletRequest` interface.
-* `getResourceBundle(Locale)` -- Returns a `ResourceBundle` for the given `Locale`. This method is specific to Sling.
-* `getResourceBundle(String, Locale)` -- Returns a `ResourceBundle` of a given base name for the given `Locale`. This method is specific to Sling.
-
-
-These methods have a default implementation in the `org.apache.sling.core` bundle and an extended and extensible implementation in the `org.apache.sling.i18n` bundle.
-
-
-## Default Implementation in the `org.apache.sling.engine` Bundle
-
-The default implementation of the above mentioned four methods in the Sling Engine bundle is contained in the bundle-private class `org.apache.sling.engine.impl.SlingHttpServletRequestImpl` which is the primary implementation of the `SlingHttpServletRequest` interface:
-
-* `getLocale()` -- Returns the `Locale` from the request object of the servlet container in which Sling is running. As per the Servlet API specification, this is either the primary Locale of the `Accept-Language` request header or the server default locale.
-* `getLocales()` -- Returns the `Enumeration` from the request object of the servlet container in which Sling is running. As per the Servlet API specification, this is either based on the `Accept-Language` request header or just the server default locale.
-* `getResourceBundle(Locale)` -- Returns a `ResourceBundle` whose `getString(String key)` method returns the `key` as the message and whose `getKeys()` method returns an empty `Enumeration`.
-* `getResourceBundle(String, Locale)` -- Returns a `ResourceBundle` whose `getString(String key)` method returns the `key` as the message and whose `getKeys()` method returns an empty `Enumeration`.
-
-
-NOTE: Unlike the default implementations of the `ResourceBundle` abstract class in the Java Runtime -- `PropertyResourceBundle` and `ListResourceBundle` -- the `ResourceBundle` returned by the default implementation of the `getResourceBundle(Locale)` and `getResourceBundle(String, Locale)` always returns a string message for any key, which is the key itself. This prevents throwing `MissingResourceException`.
-
-
-
-## Extensible Implementation in the `org.apache.sling.i18n` Bundle
-
-The `org.apache.sling.i18n` Bundle implements a request level `Filter` providing extensible implementations of the above mentioned three methods. Extensibility is attained by defining two service interfaces:
-
-* `LocaleResolver` -- The `LocaleResolver` interface defines a method which may be implemented by a service outside of the sling.i18n bundle. If no such service is registered the default behaviour is as described above for the sling.core bundle. The service described by this interface is used to implement the `getLocale()` and `getLocales()` method.
-
-* `ResourceBundleProvider` -- The `ResourceBundleProvider` interface defines two methods to acquire a `ResourceBundle` for any `Locale` and an optional base name. This service interface is not intended to be implemented outside of the sling.i18n bundle: A JCR Repository based implementation is contained in the sling.i18n bundle. The `ResourceBundleProvider` service is not only used within the sling.i18n bundle to implement the `SlingHttpServletRequest.getResourceBundle(Locale)` and `SlingHttpServletRequest.getResourceBundle(String, Locale)` methods. The service may also be used by Sling applications to acquire `ResourceBundle` instances without having a request object by getting the service and calling its `getResourceBundle(Locale)` or `getResourceBundle(String, Locale)` method directly.
-
-
-
-### JCR Repository based `ResourceBundleProvider`
-
-The sling.i18n Bundle provides the implementation of the `ResourceBundleProvider` interface, which may also be used outside of Sling requests for service tasks. This implementation gets the messages from a JCR Repository stored below nodes of the mixin node type `mix:language`. These language nodes have a `jcr:language` property naming the language of the resources. In the context of the JCR based `ResourceBundleProvider` this is of course expected to be the string value of respective `Locale`. The format may either be the format as described in [Locale.toString](http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#toString%28%29) or as described in [BCP 47](https://tools.ietf.org/html/bcp47), while for the latter you may only provide ISO 3166-1 country codes (for the region) and ISO 639-1 alpha 2 language codes (for the language). Both formats are also accepted in lower-case.
-
-The exact location of these nodes is not relevant as the `ResourceBundleProvider` finds them by applying a JCR search.
-
-Two different types of storage formats are supported for the individual dictionaries
-
-#### `sling:MessageEntry` based
-
-The (direct) child nodes of the `mix:language` node must have the `jcr:primaryType` set to `sling:MessageEntry` and must contain two special properties naming the key string and the message:
-
-* `sling:key` -- The `sling:key` property is a string property being the key for which the node contains the message(s). This property is optional. If it is not set the key is determined by the name of this `sling:messageEntry` resource.
-* `sling:message` -- The `sling:message` property represents the resource for the key.
-
-It is only required that the message nodes are located below `mix:language` nodes. Such structures may also be scattered in the repository to allow storing message resources next to where they are most likely used, such as request scripts.
-
-##### Sample Resources
-
-Content for dictionaries in this format might look like this:
-
-/libs/languages
-+-- English (nt:folder, mix:language)
-| +-- jcr:language = en
-| +-- m1 (sling:MessageEntry)
-| | +-- sling:key = "msg001"
-| | +-- sling:message = "This is a message"
-| +-- m2 (sling:MessageEntry)
-| +-- sling:key = "msg002"
-| +-- sling:message = "Another message"
-+-- Deutsch (nt:folder, mix:language)
-+-- jcr:language = de
-+-- m1 (sling:MessageEntry)
-| +-- sling:key = "msg001"
-| +-- sling:message = "Das ist ein Text"
-+-- m2 (sling:MessageEntry)
-+-- sling:key = "msg002"
-+-- sling:message = "Ein anderer Text"
-
-/apps/myApp
-+-- English (nt:folder, mix:language)
-| +-- jcr:language = en
-| +-- mx (sling:MessageEntry)
-| +-- sling:key = "msgXXX"
-| +-- sling:message = "An Application Text"
-+-- Deutsch (nt:folder, mix:language)
-+-- jcr:language = de
-+-- mx (sling:MessageEntry)
-+-- sling:key = "msgXXX"
-+-- sling:message = "Ein Anwendungstext"
-
-This content defines two languages *en* and *de* with three messages *msg001*, *msg002* and *msgXXX* each. The names of the respective resources have no significance (in case the `sling:key` is set).
-
-#### JSON-file based
-
-Since Version 2.4.2 the i18n bundle supports dictionaries in JSON-format ([SLING-4543](https://issues.apache.org/jira/browse/SLING-4543)).
-Since loading such dictionaries is much faster than loading the ones based on `sling:MessageEntry`s this format should be used preferably.
-This format is assumed if the `mix:language` resource name is ending with the extension `.json`.
-The parser will take any "key":"value" pair in the JSON file, including those in nested objects or arrays. Normally, a dictionary will be just a single json object = hash map though.
-
-##### Sample Resources
-
-Content for this format might look like this:
-
-/libs/languages
-+-- english.json (nt:file, mix:language)
-| +-- jcr:language = en
-| +-- jcr:content (nt:resource)
-| + jcr:data (containing the actual JSON file)
-+-- deutsch.json (nt:file, mix:language)
-+-- jcr:language = de
-+-- jcr:content (nt:resource)
-+ jcr:data (containing the actual JSON file)
-
-
-#### JCR Node Types supporting the JCR Repository based `ResourceBundleProvider`
-
-The sling.i18n bundle asserts the following node types:
-
-[mix:language]
-mixin
-- jcr:language (string)
-
-
-The `mix:language` mixin node type allows setting the `jcr:language` property required by the `ResourceBundleProvider` implementation to identify the message `Locale`.
-
-[sling:Message]
-mixin
-- sling:key (string)
-- sling:message (undefined)
-
-[sling:MessageEntry] > nt:hierarchyNode, sling:Message
-
-
-The `sling:Message` and `sling:MessageEntry` are helper node types. The latter must be used to create the nodes for the `sling:MessageEntry` based format.
-
-### `ResourceBundle` with base names
-
-Similar to standard Java `ResourceBundle` instances, Sling `ResourceBundle` instances may be created for base names through any of the `getResourceBundle(String, Locale)` methods. These methods use the base name parameter as a selector for the values of the `sling:basename` property of the `mix:language` nodes.
-
-The base name argument can take one three values:
-
-| Value | `ResourceBundle` selection |
-|--|--|
-| `null` | Selects messages of `mix:language` nodes ignoring the existence or absence of `sling:basename` properties |
-| Empty String | Selects messages of `mix:language` nodes which have `sling:basename` properties, ignoring the actual values |
-| Any other Value | Selects messages of `mix:language` nodes whose `sling:basename` properties has any value which matches the base name string |
-
-The `sling:basename` property may be multi-valued, that is the messages of a `mix:language` nodes may belong to multiple base names and thus `ResourceBundle` instances.
-
-### `ResourceBundle` hierarchies
-The dictionary entries for one `JcrResourceBundle` are always ordered like the resource resolver search paths, so usually
-
-1. dictionary entries below `/apps`
-2. dictionary entries below `/libs`
-3. dictionary entries anywhere else (outside the search path)
-
-That means that the message for the same key in `/apps` overwrites the one in `/libs` (if both are for the same locale and base name). Within those categories the order is non-deterministic, so if there is more than one entry for the same key in `/apps/...` (for the same locale and base name), any of those entries may be used.
-
-The resource bundles of the same base name with different locales also form a hierarchy. Each key is looked up recursively first in the current resource bundle and then in its parent resource bundle. The parent resource bundle is the one having the same base name but the parent locale.
-
-The locale hierarchy is ordered like this:
-
-1. `<Language> <Country> <Variant>`
-2. `<Language> <Country>`
-3. `<Language>`
-4. `<Default Locale>`, usually `en`
-
-So for the locale `de-DE-MAC` the fallback order would be
-
-1. `de-DE-MAC`
-2. `de-DE`
-3. `de`
-4. `en`
-
-In case there is a resource bundle requested for a locale without country or variant, there is only 1 fallback (i.e. the default locale).
-The last resort (root resource bundle in all hierarchies) is always the bundle which returns the requested key as the value.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/jconsole-hc.jpg
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/jconsole-hc.jpg b/content/documentation/bundles/jconsole-hc.jpg
deleted file mode 100644
index 4087cf9..0000000
Binary files a/content/documentation/bundles/jconsole-hc.jpg and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/jcr-installer-provider.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/jcr-installer-provider.md b/content/documentation/bundles/jcr-installer-provider.md
deleted file mode 100644
index 73fc668..0000000
--- a/content/documentation/bundles/jcr-installer-provider.md
+++ /dev/null
@@ -1,149 +0,0 @@
-title=JCR Installer Provider
-type=page
-status=published
-~~~~~~
-
-The JCR installer provider scans the JCR repository for artifacts and provides them to the [OSGI installer](/documentation/bundles/osgi-installer.html).
-
-## Configuration and Scanning
-
-The JCR installer provider can be configured with weighted paths which are scanned. By default, the installer scans in */apps* and */libs* where artifacts found in */apps* get a higher priority. The installer does a deep scan and uses a regular expression to detect folders containing artifacts to be installed. By default, artifacts from within a folder named *install* are provided to the OSGi installer.
-
-If such an install folder contains a binary artifact (e.g. a bundle or a config file as described in [Configuration Installer Factory](/documentation/bundles/configuration-installer-factory.html)) this is provided to the OSGi installer.
-
-In addition every node of type *sling:OsgiConfig* is provided as a configuration to the installer. This has the advantage of leveraging the JCR structure better than binary files, but has the known limitations outlined in [SLING-4183](https://issues.apache.org/jira/browse/SLING-4183) and [SLING-2477](https://issues.apache.org/jira/browse/SLING-2477), therefore it is recommended to stick to one of the binary formats described in [Configuration Installer Factory](/documentation/bundles/configuration-installer-factory.html).
-
-The JCR installer provider does not check or scan the artifacts itself, the detection and installation is deferred to the OSGi installer.
-
-### Runmode Support
-
-The JCR installer supports run modes for installing artifacts. By default folders named *install* are checked for artifacts. If Apache Sling is started with one (or more run modes), all folders named *install.[RUNMODE]* are scanned as well. To be precise, the folder name can be followed by any number of run modes separated by comma. For example, if started with run modes *dev*, *a1*, and *public*, folders like *install.dev*, *install.a1*, *install.public* are searched as well as *install.dev.a1*, or *install.a1.dev*.
-
-Artifacts from folders with a run mode get a higher priority. For example by default, an *install* folder underneath */libs* gets the priority *50*. For each run mode in the folder name, this priority is increased by *1*, so *install.dev* has *51* and *install.a1.dev* is *52*.
-
-## Write Back Support
-
-The JCR installer supports writing back of configurations which are changed by some other ways, e.g by using the Apache Felix web console. If this is a new configuration which was not originally stored in the repository, a new configuration is stored under */apps/sling/install*. The highest search path is used together with a configurable folder (*sling/install* in this case).
-If a configuration is changed which already exists in the repository, then it depends where the original configuration is stored. If its under */libs* a new configuration at the same path under */apps* is created. Otherwise the configuration is directly modified.
-As JCR properties do not support all Java primitive types like Integer, the write back does not generate a node of type *sling:OsgiConfig* in the repository but a properties file as described in [Configuration Installer Factory](/documentation/bundles/configuration-installer-factory.html).
-
-Write back can be turned off by configuration.
-
-### Start Level Support
-
-If the parent folder of a bundle has a name which is a number, this is used as the start level (when installing the bundle for the first time, compare with [SLING-2011](https://issues.apache.org/jira/browse/SLING-2011)). So e.g. a bundle in the path `/libs/sling/install/15/somebundle.jar` is having the start level **15**.
-
-# Example
-Here's a quick walkthrough of the JCR installer functionality.
-
-## Installation
-Start the Sling [launchpad/app](http://svn.apache.org/repos/asf/sling/trunk/launchpad/app) and make sure that the following bundles are present and started:
-* [RunMode service]({{ refs.run-modes-org-apache-sling-runmode.path }})
-* OSGi installer service ([org.apache.sling.installer.core](http://svn.apache.org/repos/asf/sling/trunk/installer/core))
-* JCR installer provider ([org.apache.sling.installer.provider.jcr](http://svn.apache.org/repos/asf/sling/trunk/installer/providers/jcr))
-
-To watch the logs produced by these modules, you can filter `sling/logs/error.log` using `egrep 'jcrinstall|osgi.installer'`.
-
-## Install and remove a bundle
-
-We'll use the [Knopflerfish Desktop](http://www.knopflerfish.org/releases/2.0.5/jars/desktop_awt/desktop_awt_all-2.0.0.jar) bundle for this example, it is convenient as it displays a graphical user interface when started.
-
-We use `curl` to create content, to make it easy to reproduce the example by copying and pasting the `curl` commands. Any other way to create content in the repository will work, of course.
-
-By default, JCRInstall picks up bundles found in folders named *install* under `/libs` and `/apps`, so we start by creating such a folder:
-
-
-curl -X MKCOL http://admin:admin@localhost:8888/apps/jcrtest
-curl -X MKCOL http://admin:admin@localhost:8888/apps/jcrtest/install
-
-
-And we copy the bundle to install in that folder (a backslash in command lines means *continued on next line*):
-
-
-curl -T desktop_awt_all-2.0.0.jar http://admin:admin@localhost:8888/apps/jcrtest/install/desktop_awt_all-2.0.0.jar
-
-
-That's it. After 2-3 seconds, the bundle should be picked up by JCRInstall, installed and started. If this works you'll see a small *Knopflerfish Desktop* window on your desktop, and Sling's OSGi console can of course be used to check the details.
-
-Removing the bundle from the repository will cause it to be uninstalled, so:
-
-
-curl -X DELETE http://admin:admin@localhost:8888/apps/jcrtest/install/desktop_awt_all-2.0.0.jar
-
-
-Should cause the *Knopflerfish Desktop* window to disappear as the bundle is uninstalled.
-
-
-## Install, modify and remove a configuration
-JCRInstall installs OSGi configurations from nodes having the *sling:OsgiConfig* node type, found in folders named *install* under the installation roots (/apps and /libs).
-
-Let's try this feature by creating a configuration with two properties:
-
-
-curl -F "jcr:primaryType=sling:OsgiConfig" -F foo=bar -F works=yes http://admin:admin@localhost:8888/apps/jcrtest/install/some.config.pid
-
-
-And verify the contents of our config node:
-
-curl http://admin:admin@localhost:8888/apps/jcrtest/install/some.config.pid.json
-
-
-Which should display something like
-
-{"foo":"bar",
-"jcr:created":"Wed Aug 26 2009 17:06:40GMT+0200",
-"jcr:primaryType":"sling:OsgiConfig","works":"yes"}
-
-
-At this point, JCRInstall should have picked up our new config and installed it. The logs would confirm that, but we can also use the OSGi console's config status page (http://localhost:8888/system/console/config) to check it. That page should now contain:
-
-
-PID=some.config.pid
-BundleLocation=Unbound
-_jcr_config_path=jcrinstall:/apps/jcrtest/install/some.config.pid
-foo=bars
-service.pid=some.config.pid
-works=yes
-
-
-Indicating that the configuration has been installed.
-
-Let's try modifying the configuration parameters:
-
-
-curl -F works=updated -F even=more http://admin:admin@localhost:8888/apps/jcrtest/install/some.config.pid
-
-
-And check the changes in the console page:
-
-
-PID=some.config.pid
-BundleLocation=Unbound
-_jcr_config_path=jcrinstall:/apps/jcrtest/install/some.config.pid
-even=more
-foo=bars
-service.pid=some.config.pid
-works=updated
-
-
-We can now delete the configuration node:
-
-
-curl -X DELETE http://admin:admin@localhost:8888/apps/jcrtest/install/some.config.pid
-
-
-And verify that the corresponding configuration is gone in the console page (after 1-2 seconds, like for all other JCRInstall operations).
-
-A node named like `o.a.s.foo.bar-a` uses *o.a.s.foo.bar* as its factory PID creating a configuration with an automatically generated PID. The value of *a* is stored as an alias in the OSGi installer to correlate the configuration object with the repository node.
-
-# Automated Tests
-The following modules contain lots of automated tests (under `src/test`, as usual):
-
-* OSGi installer integration tests ([org.apache.sling.installer.it](http://svn.apache.org/repos/asf/sling/trunk/installer/it))
-* JCR installer service ([org.apache.sling.installer.providers.jcr](http://svn.apache.org/repos/asf/sling/trunk/installer/providers/jcr))
-
-Many of these tests are fairly readable, and can be used to find out in more detail how these modules work.
-
-# Project Info
-
-* JCR installer provider ([org.apache.sling.installer.provider.jcr](http://svn.apache.org/repos/asf/sling/trunk/installer/providers/jcr))
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/log-tracers.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/log-tracers.md b/content/documentation/bundles/log-tracers.md
deleted file mode 100644
index b6630a5..0000000
--- a/content/documentation/bundles/log-tracers.md
+++ /dev/null
@@ -1,243 +0,0 @@
-title=Log Tracer
-type=page
-status=published
-~~~~~~
-
-[Log Tracer][SLING-4739] provides support for enabling the logs for specific category at specific
-level and only for specific request. It provides a very fine level of control via config provided
-as part of HTTP request around how the logging should be performed for given category.
-
-This is specially useful for those parts of the system which are involved in every request.
-For such parts enabling the log at global level would flood the logs and create lots of noise.
-Using Tracer one can enable log for that request which is required to be probed.
-
-For e.g. determining what nodes are written for a given POST request can be simply done by including
-an extra request parameters.
-
-curl -D - -u admin:admin -d "./jcr:content/jcr:title=Summer Collection" -d ":name=summer-collection" -d "./jcr:primaryType=sling:Folder" -d "./jcr:content/jcr:primaryType=nt:unstructured" -d "tracers=oak-writes" http://localhost:4502/content/dam/
-
-## Configuration
-
-
-
-**Note that by default Tracer would not be enabled and you would need to save the OSGi config to
-get it activated**
-
-Tracer support two ways to enable logging.
-
-### Tracer Sets
-
-Tracer sets are collection of predefined logging categories matching specific area of an application.
-These can for now be configured as part of OSGi config
-
-oak-query : org.apache.jackrabbit.oak.query.QueryEngineImpl;level=debug
-auth : org.apache.sling.auth;level=trace,org.apache.jackrabbit.oak.security
-
-The config is of following format
-
-< set name > : <tracer config>
-
-Where the config is of following format
-
-tracerConfig := loggerConfig ( ',' loggerConfig) *
-loggerConfig := loggerName (; attributes)*
-attributes := attributeName '=' attributeValue
-
-Currently following attributes are support
-
-* `level` - Either of TRACE, DEBUG, INFO, WARN, ERROR
-* `caller` - Used to dump stacktrace of caller. It can have following value (_since 1.0.0_, [SLING-5505][SLING-5505])
-* `true` - Complete call stack for that logger would be included
-* `<depth>` - Call stack upto depth (integer) would be included e.g. caller=5
-* `caller-exclude-filter` - (optional) - '|' separated package prefixes which should not be
-included in the output. e.g. _org.apache.jackrabbit.oak.query.QueryImpl;caller=28;caller-exclude-filter="org.eclipse|org.felix"_
-this would exclude eclipse and felix packages from the resulting stack
-
-### Performance Impact
-
-Tracer makes use of [Logback TuboFilter][1] to intercept the logging calls and only enable them for
-those which are enabled via tracer config for the request. The filter is only registered for the
-duration of that request hence would avoid adding the cost for normal run.
-
-You can also disable the Tracer completely via OSGi config.
-
-## Where do logs go
-
-The logs captured are logged at two places
-
-### RequestProgressTracker
-
-Sling provides support for recording recent requests which can be accessed via [Recent Requests
-Plugin][2]. It would list down the list of recent request and then on clicking them you can see the
-logs showed on the UI.
-
-The logging there is done via [RequestProgressTracker][3] ([intro][4]). By default recent request
-plugin gets overflown as it captures request even for css, js files. To avoid that you can modify
-the config as part of _Sling Main Servlet_ config
-
-
-
-Using a regex like ```^.*.(?!jpg$|png$|js$|css$|woff$)[^.]+$``` would avoid noise
-
-With that you can see log entries like below at http://localhost:8080/system/console/requests?index=xxx
-
-132 (2015-05-11 17:39:55) LOG [JCR] Query SELECT * FROM [granite:InboxItem] AS s where status='ACTIVE' ORDER BY s.startTime DESC
-134 (2015-05-11 17:39:55) TIMER_END{53,/libs/cq/gui/components/endor/badge/badge.jsp#18}
-...
-1316 (2015-05-11 17:39:56) LOG JCR Query Count 3
-1320 (2015-05-11 17:39:56) TIMER_END{1320,Request Processing} Request Processing
-
-### Server Logs
-
-Further the logs also go to normal server side logs. By default they would go to the error.log. If
-you have routed the logs of specific categories to different files then normal Logback logging rules
-would apply
-
-## Usage
-
-Tracing can be done in various ways for a given HTTP request. Tracer looks for following hints as part of request
-
-* Tracer set names - Comma separated list of tracer set names which need to be enabled. e.g. `oak-query, oak-writes` etc
-* tracerConfig - Raw tracing config only used for that specific request
-
-### Request Parameters
-
-Param names
-
-* `tracers` - Tracer set names
-* `tracerConfig` - Tracer config like org.apache.sling.auth;level=trace`
-
-curl -u admin:admin http://localhost:4802/projects.html?tracerConfig=org.apache.sling
-
-Above request would turn on debug level logging (default level for tracer) for `org.apache.sling` category.
-
-curl -D - -u admin:admin -d "./jcr:content/jcr:title=Summer Collection" -d ":name=summer-collection" -d "./jcr:primaryType=sling:Folder" -d "./jcr:content/jcr:primaryType=nt:unstructured" -d "tracers=oak-writes" http://localhost:4502/content/dam/
-
-Above request would create a folder in Assets and for that we have enabled the `oak-writes` tracer. This would result in following output
-
-2015-05-11 17:30:42,840 INFO admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] c.a.acs.acs-aem-tools-bundle - Service [4858] ServiceEvent REGISTERED
-2015-05-11 17:30:42,846 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] Adding node [/content/dam/summer-collection]
-2015-05-11 17:30:42,849 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] setPrimaryType
-2015-05-11 17:30:42,849 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] Adding node [/content/dam/summer-collection/jcr:content]
-2015-05-11 17:30:42,849 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] Setting property [/content/dam/summer-collection/jcr:content/jcr:title]
-2015-05-11 17:30:42,850 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] setPrimaryType
-2015-05-11 17:30:42,850 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] setPrimaryType
-2015-05-11 17:30:42,856 TRACE admin [127.0.0.1 [1431345642836] POST /content/dam/ HTTP/1.1] o.a.j.o.jcr.operations.writes session-12895- [session-12895] save
-
-### Request Headers
-
-Some request like initial authentication processing does not involve Sling MainServlet and hence for
-those request logging cannot be done to RequestProgressTracker. Instead we can just get logs enabled
-and route them to normal logging on server side. For that you need to use HTTP header
-
-* `Sling-Tracers` - Set of tracer set names
-* `Sling-Tracer-Config` - Tracer config
-
-So to enable authentication related logging following request can be sent
-
-curl -D - -d "j_username=admin" -d "j_password=admin" -d "j_validate=true" -H "Sling-Tracer-Config : org.apache.sling.auth;level=trace,org.apache.jackrabbit.oak.security;level=trace" http://localhost:8080/libs/content/login.html/j_security_check
-
-This would result in following server side logs
-
-2015-05-11 17:34:56,531 INFO NA [qtp1395423247-193] c.a.acs.acs-aem-tools-bundle - Service [4859] ServiceEvent REGISTERED
-2015-05-11 17:34:56,532 DEBUG NA [qtp1395423247-193] o.a.s.a.c.i.SlingAuthenticator - doHandleSecurity: Trying to get a session for null
-2015-05-11 17:34:56,532 DEBUG NA [qtp1395423247-193] o.a.j.o.s.a.LoginContextProviderImpl - Found pre-authenticated subject: No further login actions required.
-2015-05-11 17:34:56,532 DEBUG NA [qtp1395423247-193] o.a.j.o.s.a.LoginContextProviderImpl - Found pre-authenticated subject: No further login actions required.
-2015-05-11 17:34:56,548 DEBUG NA [qtp1395423247-193] o.a.j.o.s.a.u.LoginModuleImpl - Adding Credentials to shared state.
-2015-05-11 17:34:56,548 DEBUG NA [qtp1395423247-193] o.a.j.o.s.a.u.LoginModuleImpl - Adding login name to shared state.
-
-## Tracer Recording
-
-_Since 1.0.0 [SLING-5459][SLING-5459]_
-
-Apart from routing the logs to the server logs they can also be stored in memory and accessed in
-json form from Felix Web Console. By default support for recording is disabled and it needs to be
-explicitly enabled via OSGi config
-
-Recording features works as explained below
-
-1. Client sends an HTTP request with header `Sling-Tracer-Record` set to `true`
-
-curl -D - -u admin:admin -H "Sling-Tracer-Record : true" -d "./jcr:content/jcr:title=Summer Collection" -d ":name=summer-collection" -d "./jcr:primaryType=sling:Folder" -d "./jcr:content/jcr:primaryType=nt:unstructured" -d "tracers=oak-writes" http://localhost:4802/content/dam/
-
-2. Server includes a request id as part of `Sling-Tracer-Request-Id` response headers
-
-HTTP/1.1 201 Created
-Date: Wed, 27 Jan 2016 07:30:22 GMT
-Sling-Tracer-Request-Id: 9b5b01f6-f269-47c3-a889-2dc8d4d7938f
-X-Content-Type-Options: nosniff
-X-Frame-Options: SAMEORIGIN
-Location: /content/dam/summer-collection
-Content-Type: text/html; charset=UTF-8
-Transfer-Encoding: chunked
-
-3. The logs in json format can then be fetched from server at `/system/console/tracer` like
-http://localhost:8080/system/console/tracer/9b5b01f6-f269-47c3-a889-2dc8d4d7938f.json.
-
-curl -s -D - -H "Sling-Tracer-Record : true" -H "Sling-Tracers : oak-query" -H "Sling-Tracer-Config : org.apache.jackrabbit.oak.query" -u admin:admin http://localhost:4512/assets.html/content/dam -o /dev/null
-
-Below is a json output for GET request
-
-:::javascript
-{
-"method": "GET",
-"time": 15140,
-"timestamp": 1461574009024,
-"requestProgressLogs": [
-"0 TIMER_START{Request Processing}",
-"0 COMMENT timer_end format is {<elapsed msec>,<timer name>} <optional message>",
-...
-],
-"queries": [{
-"query": "/jcr:root/etc/workflow/instances//element(*,app:Workflow)[@status='RUNNING'] order by @startTime descending",
-"plan": "[app:Workflow] as [a] /* property status = RUNNING where ([a].[status] = 'RUNNING') and (isdescendantnode([a], [/etc/workflow/instances])) */",
-"caller": "com.example.WorkflowManager.getWorkflowInstances(WorkflowManager.java:902)"
-}
-],
-"logs": [{
-"timestamp": 1461574022401,
-"level": "DEBUG",
-"logger": "org.apache.jackrabbit.oak.query.QueryEngineImpl",
-"message": "Parsing xpath statement: /jcr:root/etc/workflow/instances//element(*,cq:Workflow)[@status='RUNNING'] order by @startTime descending",
-"params": [
-"xpath",
-"/jcr:root/etc/workflow/instances//element(*,cq:Workflow)[@status='RUNNING'] order by @startTime descending"
-]
-}
-...
-]
-}
-
-JSON output consist of following sections
-
-1. `method` - Request method
-2. `time` - Time in mills spent in request processing on server
-3. `timestamp` - Request start time
-4. `requestProgressLogs` - Sling Request Progress Tracker log for the given request
-5. `queries` - List of queries fired along with details around `query`, `plan` and `caller` i.e. from where
-the query is invoked
-6. `logs` - List of log entries captured (as enabled by tracer config) for current request
-
-The recordings are held in memory for 15 mins (per default setting) and can be seen listed at http://localhost:8080/system/console/tracer. Look into the OSGi config for more config options
-around this.
-
-## Installation
-
-Download the bundle from [here][5] or use following Maven dependency
-
-::xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.tracer</artifactId>
-<version>1.0.0</version>
-</dependency>
-
-
-[1]: http://logback.qos.ch/manual/filters.html#TurboFilter
-[2]: https://sling.apache.org/documentation/development/monitoring-requests.html
-[3]: https://sling.apache.org/apidocs/sling5/org/apache/sling/api/request/RequestProgressTracker.html
-[4]: http://dev.day.com/content/ddc/blog/2008/06/requestprogresstracker.html
-[SLING-4739]: https://issues.apache.org/jira/browse/SLING-4739
-[SLING-5505]: https://issues.apache.org/jira/browse/SLING-5505
-[SLING-5459]: https://issues.apache.org/jira/browse/SLING-5459
-[5]: http://sling.apache.org/downloads.cgi