- (TODO: breadcrumb here) +Home

The Sling Launchpad

{toc:minLevel=2|maxLevel=3}

This tries to explain how exactly the Sling Launchpad works, what -constitutes the Sling Launchpad and how you can use the Sling Launchpad to -custom create you Sling launchers. For a view behind the scenes of the -Sling Launchpad Base module (the actual launcher) you might want to refer -to the Embedding Sling - page.

Sling Home

Since Sling requires some space on the filesystem to store various files -Sling has to know where this filesystem space is located.

The following is a list of uses for the Sling Home directory:

sling.properties -- The main configuration file used by Sling to -launch the framework. It mainly contains OSGi framework configuration and -initial configuration for some bundles. This file is read on each startup -of Launcher JAR. That is, changes to this file require a restart of the -Launcher JAR.
org.apache.sling.launchpad.base.jar -- This is the Launcher JAR -file used by the Standalone Application or the Web Application to start the -OSGi Framework. This file is initially placed when first starting Sling and -may later be updated by updating the system bundle with a new Launcher -JAR.
felix -- The directory into which the Apache Felix Framework places -the bundles, which have been installed into the system. This does generally -not need to be touched.
config -- The directory into which the Apache Felix Configuration -Admin Service stores the configurationes. Do not change any files in this -directory, since changes will not generally be picked up.
jackrabbit -- The directory in which the Apache Jackrabbit JCR -repository is started. Amongst other things this also contains the -Jackrabbit configuration file repository.xml. You may modify this file, -but don't forget to restart the Embedded Jackrabbit Repository bundle after -doing this.
logs -- Contains the log files generated by Sling. By default this -contains the error.log and its rotated generations.

Command Line Options

The Java Standalone Application supports a number of command line options, -which influence the operation of the launch process.

- - - - - - - - - - - - -

Option	Argument	Description
start	--	Open a TCP/IP server socket when starting Sling. Uses -option -j to define the local socket address.
status	--	Check whether a (remote) Sling application is running. -Uses option -j to define the address of the Sling instance to check. -Note, that the Sling application terminates after checking for the (remote) -Sling status.
stop	--	Stop a (remote) Sling application is running. Uses option --j to define the address of the Sling instance to stop. Note, that the -Sling application terminates after stopping the (remote) Sling instance.
-c	slinghome	The directory in which Sling locates its initial -configuration file sling.properties and where files of Sling itself -such as the Apache Felix bundle archive or the JCR repository files are -stored. This defaults to the sling folder in the current working -directory. This is the value which is commonly refered to as -$\{sling.home}. -
-l	loglevel	Sets the initial loglevel as an integer in the range -0 to 4 or as one of the well known level strings ERROR, WARN, -INFO, or DEBUG. This option overwrites the -org.apache.sling.osg.log.level setting the sling.properties file. -The default is INFO.
-f	logfile	The log file to use or - to log to standard out. -This option overwrites the org.apache.sling.osg.log.file setting the -sling.properties file. The default is -$\{sling.home}/logs/error.log.
-a	address	The interfact to bind to (use 0.0.0.0 for any). This -option is not implemented yet.
-p	port	The port to listen (default 8080) to handle HTTP -requests. This option overwrites the org.osgi.service.http.port setting -the sling.properties file.
-j	[ host ":" ](-host-":"-.html) - port	The socket address to listen on for control connections (start -or to use as the remote endpoint for the control connection (status and -stop. If this parameter has no arguments or is not specified, the -address defaults to port 63000 on localhost/127.0.0.1. If only the port is -specified localhost/127.0.0.1 is used as the host part of the address.
-h	--	Prints a simple usage message listing all available command -line options.

+ -

The Sling Standalone application looks for a definition of the -sling.home setting in the following locations in order of precendence:

The -c command line option
The sling.home system property
The SLING_HOME environment variable
If none of the above resolves to a non-null value, the default value of -sling is assumed

Security Implication

Note that using a control connection for the Sling Standalone Application -presents a potential security issue. For this reason the following defaults -apply:

The server side socket for a running Sling Standalone Application is only -created if the application is started with the start command line -option. If this option is omitted -- the default -- the server side socket -is not created and the Sling Standalone Application instance cannot be -remotely controlled.
The default host name for the socket is localhost/127.0.0.1 meaning that -the socket is only accessible from the same system as the Sling Standalone -Application is running on. If the socket is accessible from remote systems -additional must be taken to prevent malicious attackers to stop the system. -The server side control connection implementation implements no security -precaution (except from supporting to not create such a connection at all).

Servlet Parameters

The Web Application does not require specific servlet parameters. Those -which are specified are used to overwrite any properties with the same name -from the sling.properties file. One exception to this rule is the -sling.home parameter, which is used to set the value of the -sling.home property. If no parameter with this name is defined the -Sling home directory is derived from the context path at which the Sling -Web Application is registered.

The sling.home folders for Sling Web Applications without the -sling.home servlet parameter are all located in the sling folder in -the current working directory as reported by the user.dir system -property. The name of the actual directory is derived from the Web -Application Context Path by replacing all slash characters / by -underscore characters _. For the root context a single underscore -character _ is used.

Examples:

- - - - - -

Servlet Context	Default sling.home
_root_	sling/\_
/sling	sling/\_sling
/sling/instance1	sling/\_sling\_instance1

- -

Starting with Launchpad Base 2.2.2 the fixed prefix sling is -configurable with the sling.home.prefix system property. If this -property is set the value used as the prefix.

Examples: Assume the sling.home.prefix system property is set to -/var/sling

- - - - - -

Servlet Context	Default sling.home
_root_	/var/sling/\_
/sling	/var/sling/\_sling
/sling/instance1	/var/sling/\_sling\_instance1

- -

sling.properties

The sling.properties file contains the initial setup of the Sling -Application and the OSGi framework. Some of the parameters are required and -should not be modified without a very good reason. Some parameters may be -freely modified to your needs. Please see the inlined comment in the -sling.properties file installed when Sling is first started.

One thing to note is, that the sling.properties file is a simple Java -Properties file with support for property references. That is, the value of -properties may refer other property values by means of the well known -${name} notation. Such property references may even be cascaded as in

java.packages=${jre-${java.specification.version}}
-

- - -

Components

The Sling Launchapd consists of Launchbad Base project and three -additional projects which ultimately create a Standalone Java Application -and a Web Appliction with standard parts of Sling.

Launchpad Base

The Launchpad Base projects creates the following artifacts, which are -required in actual setups to get a Sling application:

-
Launcher JAR -- The primary artifact of the Base project contains the -actual support to launch the Apache Felix OSGi Framework and install -bundles, which are packaged with the application. It also contains the -Apache Felix Framework together with the OSGi R4.1 Core and Compendium -libraries as well as the Equinox HttpService bridge and the Servlet API.
-
-
App JAR -- The secondary artifact with classifier app is a minimal -Standalone Java Application which may be started by simply typing
-
$ java -jar org.apache.sling.launchpad.base-app.jar
-
-
Web App Archive -- The secondary artifact with classifier webapp is a -minimal Web Application, which may simply be deployed into your favirourite -servlet container, provided it supports at least Servlet API 2.4.
-
-
Source JAR -- The secondary artifact with the classifier sources is -simple the source of the Launchpad Base project.
-

To build a very basic Sling launcher, the Launchpad Base is actually all -you need. But to really glue this together and get a usable system, some -more work is required. Lets see how the additionaly projects Launchpad -Bundles, Launchpad App, and Launchpad WebApp get to that.

Launchpad Bundles

The second project we want to look at is the Launchpad Bundles project. -This is a very simple project in that it only collects together a number of -OSGi bundles, which will make up the final application. The bundles are -stored in a (big) Java Archive in folders whose path is formed with -resources/9 where 9 is a start level which is assigned to the -bundles as they are installed. The special start level 0 instructs the -installer to not actually assign a specific start level to the bundles -contained in that folder.

Currently the following start level assignement is used by the Launchpad -Bundles project:

- - - - - - -commons-lang, jackrabbit-api, jackrabbit-jcr-commons, -org.apache.sling.commons.mime, org.apache.sling.commons.osgi, -org.apache.sling.jcr.api, org.apache.sling.jcr.base, -org.apache.sling.jcr.jackrabbit.server, org.apache.sling.jcr.webdav | - -

Start Level	Bundle Group	Bundle(s)
1	Basic bundles required for the correct operation of Sling	-org.apache.sling.commons.log -
5	Apache Felix Web Console	org.apache.felix.bundlerepository, -org.apache.felix.webconsole, org.apache.sling.extensions.threaddump
10	OSGi Compendium Service Implementations	-org.apache.felix.configadmin, org.apache.felix.eventadmin, -org.apache.felix.metatype, org.apache.felix.scr
15	JCR Repository (Jackrabbit)	commons-collections, -commons-io-1.4.jar -
0	Actual Sling Application bundles	org.apache.sling.adapter, -org.apache.sling.api, org.apache.sling.bundleresource.impl, -org.apache.sling.commons.json, org.apache.sling.engine, -org.apache.sling.extensions.apt.parser, -org.apache.sling.extensions.apt.servlet, org.apache.sling.httpauth, -org.apache.sling.jcr.classloader, org.apache.sling.jcr.contentloader, -org.apache.sling.jcr.ocm, org.apache.sling.jcr.resource, -org.apache.sling.launchpad.content, -org.apache.sling.samples.path-based.rtp, org.apache.sling.scripting.api, -org.apache.sling.scripting.core, org.apache.sling.scripting.javascript, -org.apache.sling.scripting.jsp, org.apache.sling.scripting.jsp.taglib, -org.apache.sling.servlets.get, org.apache.sling.servlets.post, -org.apache.sling.servlets.resolver

- -

Launchpad App and Launchpad WebApp

The Launchpad App and Launchpad WebApp bundles are actually projects -which just glue together artifacts from the Launchpad projects. There is -nothing special about them. Here's what is done:

Take the appropriate secondary artifact from the Launchpad Base -project: app for the Standalone Java Application or webapp for the Web -Application and unpack
Take the Launchpad Base primary artifact and place it under the name -org.apache.sling.launchpad.base.jar into the resources folder
Take the Launchpad Bundles artifact and unpack it
Finally pack all together into a single big JAR or WAR file

That's it. The resulting artifact may be directly used to launch the -Standalone Java Application or may directly be deployed into any Servlet -API 2.4 (or later) compliant servlet container.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/url-decomposition.html ============================================================================== --- websites/staging/sling/trunk/content/url-decomposition.html (original) +++ websites/staging/sling/trunk/content/url-decomposition.html Sun Apr 22 17:09:56 2012 @@ -79,60 +79,10 @@

- (TODO: breadcrumb here) +Home

URL decomposition

During the Resource Resolution step, the client request URL is decomposed -into the following parts:

Resource Path - The longest substring of the request URL such that the -resource path is either the complete request URL or the next character in -the request URL after the resource path is a dot (.).
Selectors - If the first character in the request URL after the -resource path is a dot, the string after the dot up to but not including -the last dot before the next slash character or the end of the request URL. -If the resource path spans the complete request URL no seletors exist. If -only one dot follows the resource path before the end of the request URL or -the next slash, also no selectors exist.
Extension - The string after the last dot after the resource path in -the request URL but before the end of the request URL or the next slash -after the resource path in the request URL.
Suffix Path - If the request URL contains a slash character after the -resource path and optional selectors and extension, the path starting with -the slash up to the end of the request URL is the suffix path. Otherwise, -the suffix path is empty. Note, that after the resource path at least a dot -must be in the URL to let Sling detect the resource path.

There's a cheat sheet on Day's dev page under http://dev.day.com/content/docs/en/cq/current/developing/sling_cheatsheet.html - available to get you familiar with the URL decomposition of Sling.

Examples: Assume there is a Resource at /a/b, which has no children.

- - - - - - - - - - - - - - - -

URI	Resource Path	Selectors	Extension	Suffix	Resource -Found
/a/b	/a/b	null	null	null	yes
/a/b.html	/a/b	null	html	null	yes
/a/b.s1.html	/a/b	s1	html	null	yes
/a/b.s1.s2.html	/a/b	s1.s2	html	null	yes
/a/b/c/d	/a/b/c/d	null	null	null	no!
/a/b./c/d	/a/b	null	null	/c/d	yes
/a/b.html/c/d	/a/b	null	html	/c/d	yes
/a/b.s1.html/c/d	/a/b	s1	html	/c/d	yes
/a/b.s1.s2.html/c/d	/a/b	s1.s2	html	/c/d	yes
/a/b/c/d.s.txt	/a/b/c/d	s	txt	null	no!
/a/b.html/c/d.s.txt	/a/b	null	html	/c/d.s.txt	yes
/a/b.s1.html/c/d.s.txt	/a/b	s1	html	/c/d.s.txt	yes
/a/b.s1.s2.html/c/d.s.txt	/a/b	s1.s2	html	/c/d.s.txt	yes

+ -

{info:title=Automated tests and examples} -The SlingRequestPathInfoTest - demonstrates and tests this decomposition. Feel free to suggest additional -tests that help clarify how this works! -{info}

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/version-policy.html ============================================================================== --- websites/staging/sling/trunk/content/version-policy.html (original) +++ websites/staging/sling/trunk/content/version-policy.html Sun Apr 22 17:09:56 2012 @@ -79,294 +79,10 @@

- (TODO: breadcrumb here) +Home

Version Policy

DRAFT 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.{excerpt}

{info} -Please note that this page is currently in draft stage and still being -discussed. -{info}

{toc:minLevel=2|maxLevel=2}

Introduction

In comments to SLING-1176 Ian Boston wrote:

{quote} -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. [...](....html) - [The problem is the] manual maintenance of the version numbers. (not a -big problem but needs to be done) -{quote}

I agree, that this is a problem. So let me reasonate on this a bit ;-)

As a reference you might want to read my blog post on version numbers - and also what the [Eclipse guys have to say|http://wiki.eclipse.org/index.php/Version_Numbering] - (great read, btw). The OSGi Alliance has come up with a good definition -for [Semantic Versioning|http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf] - to which the definitions described below perfectly match.

For Sling we have three kinds of version numbers:

Big Sling Releases
Sling Bundles
Package Exports

Big Sling Releases

For Big Sling releases we already have an ample solution in that we just -use a single number increased from release to release. Just remember that a -Big Sling release is a convenience release of existing released Sling -bundles.

Sling Bundles

For Sling Bundles version numbers are just defined as the -element of the bundle's POM. The only restriction here is, that we decided -to use even numbers for releases and odd numbers for SNAPSHOTs. Whether and -when which version part is increased is not explicitly defined yet.

Package Exports

For Package Exports the situation is more problematic since there are a -number of places to set exported package version number:

In a packageinfo file inside the package (picked up by the Maven -Bundle Plugin to set the export version)
Explicitly in the element of the Maven Bundle -Plugin configuration
By reference to the bundle version number using the ${pom.version} -variable.

Upto now, we mostly used the ${pom.version notation linking the -exported package version to the bundle version. Over time this mechanism -leads to a number of problems:

For bundles with more than one package exported, the exported packages -will evolve independently. As a consequence their versionin should also -evolve independently. An example of such a bundle is the Sling API bundle -of course.
Linking the package export version number to the bundle version number -confuses the actual semantics of both version numbers. The package export -version number only indicates the version of the actual package while the -bundle version number indicates a development state of the overall bundle. -This will generally not be the same.
The version of the exported package is increased on each bundle -release, even though nothing may have changed on the export. In such a -situation the version of the export should stay the same.

That said, the reuse of the bundle version as the package export version -still is probably the correct thing to do for legacy library wrappers.

Consider for example the Sling API bundle, which exports 9 packages. Each -of which may evolve independently. Now the resource package is extended -causing a minor version increase. Should the version numbers of the other -exports also be increased ? Thus acting as if there was some API change ?

I would say, no. Particularly if some API implementation bundle is -restricting the import version of the API implemented. Such an -implementation would immediately stop working because the version has been -increased. But since there has been no change, the implementation would -still be correct.

So, I think, we should evolve the exported package versions independently -from each other and even independently from the bundle version.

This places more burden on the developer when deciding on the exported -package version - in fact this requires such a decision as compared to have -Maven take the decision by just setting the bundle version.

The only problem is: Where shall this be noted ? In the POM or in the -packageinfo file ? If we would place the packageinfo file just -beneath the class source files, I would say, in the packageinfo file.

But this would require defining the class source locations as resource -location in the POM (at least for packageinfo) files.

I am not sure ....

This has not been discussed at large, but I would assume, that the POM is -still the correct place to take note of the version of the exported -packages.

Future

The newest versions of the BND library also support an @Export -annotation in the package-info.java pseudo class file. This pseudo -class is supported starting with Java 5 to take package level annotations -(like the @Export annotation) and as a replacement of the -package-info.html file.

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;
-

+ - -

See Bnd Experimental - for details. Unfortunately the current Maven Bundle Plugin version does -not support updating to the most recent BND library versions due to -incompatibilities.

Version Number Syntax

As a small reminder, this is how a version number is constructed: In OSGi -version numbers are composed of four (4) segments: 3 integers and a string -named major.minor.micro.qualifier.

Each segment captures a different intent:

* the major segment indicates breakage in the API
-* the minor segment indicates _externally visible_ changes
-* the micro segment indicates bug fixes
-* the qualifier segment is not generally used but may be used to convey
-

- - -

more information about a particular build, such as a build time or an SVN -revision number.

Evolution of Exported Package Versions

Version numbers of exported packages evolve independently from each other. -Depending on the changes applied, the micro, minor, or major segement is -increased. Whenever the major segment is increased, the minor and micro -segments are reset to zero. Whenever the minor segment is increased, the -micro segment is reset to zero.

Segments are increased according to the above listing.

This requires committers to think well about changes they apply to exported -packages:

Removing interfaces, methods or constants is likely an API breakage and -thus requires a major version increase. In Sling we try to prevent this -from happening.
Adding new methods to interfaces is likely just an externally visible -change and thus requires a minor version increase
Fixing a bug in an exported class just requires a minor version -increase.

JavaDoc updates generally do not constitute a reason to evolve the version -number. The exception is that if the JavaDoc update is caused by a API -limitation, it might be conceivable to increase the version number of the -exported package. A decision on this will have to be taken on a -case-by-case basis.

Evolution of Bundle Versions

Version numbers of bundles evolve depending on the evolution of the -exported packages but also depending on the evolution of the private code, -which is not exported.

As a rule of thumb, the following reasons apply for increasing the segments -of bundle version numbers:

Increasing the major version number of any of the exported packages or -restructuring the bundle such that major parts are removed from the bundle -(and either completely removed or moved to other bundle(s)).
Increasing the minor version number of any of the exported packages or -refactoring the internal code or implementing a package exported by another -bundle whose minor (or even major) version number has increased. Also -functional extensions of the internal bundle classes consitutes a reason to -increase the minor version number.
Increasing the micro version number of any of the exported packages or -bug fixes.

Note, that this definition does not require the bundle and epxorted package -version numbers to be synchronized in any way. While doing so might help in -a first or second step, over time it will become close to impossible to -keep the versions in sync. So rather than trying to keep the versions in -sync, we should make sure, we increase the versions correctly.

Examples

Pure API Bundle

An example of an almost Pure API Bundle is the Sling API bundle. This -bundle exports 9 packages. Some are really stable -- e.g. the -org.apache.sling.api package or the org.apache.sling.wrappers -package -- and some are being worked on at the moment -- e.g. the -org.apache.sling.resource package.

To not break existing users of the unmodified packages, the exported -versions of these packages must not be increased.

To signal to users of evolving packages, that there might be new and -interesting functionality, the version number must be increased according -to above definition. This also conveys to the implementor(s) of the API, -that they have to take some action.

A hypothetical evolution of version numbers shown on two packages and the -bundle version might be as follows

- - - - - - - -

Description	api package	resource package	bundle
Initial Release	1.0.0	1.0.0	1.0.0
Bug fix in a resource class	1.0.0	1.0.2	1.0.2
New API in the resource package	1.0.0	1.1.0	1.1.0
New API in the api package	1.1.0	1.1.0	1.2.0
API breakage in the api package	2.0.0	1.1.0	2.0.0

- -

Implementation Bundle providing API

An example of such a hybrid bundle is the Sling Engine bundle. This bundle -exports two packages themselves defining API and contains a number of -internal packages which actually implement parts of the Sling API.

A hypothetical evolution of version numbers shown on one exported package -and the bundle version might be as follows

- - - - - - - - - -

Description	engine package	bundle
Initial Release	1.0.0	1.0.0
Bug fix in a engine class	1.0.2	1.0.2
Bug fix in an internal calss	1.0.2	1.0.4
New API in the engine package	1.1.0	1.1.0
Implement new API from api 1.1.0	1.1.0	1.2.0
Refactor internal classes	1.1.0	1.3.0
Implement API from api 2.0.0	1.1.0	2.0.0

- -

Pure Implementation Bundle

For Pure Implementation Bundles only the bundle version numbers are -maintained because there is no exported package whose version number needs -to be managed. This makes the decision process of version number evolution -very simple.

Importing Packages

When importing packages a version number will automatically be generated by -the Maven Bundle Plugin as follows:

If the providing package exports a package with an explicit version -number, that exact version number will be used as the lower bound
If such a lower bound exists, the upper bound is exclusive the next -major version number.

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)
-

- - -

This default works well for consumers of the API, since according to above -definitions an API is guaranteed to not contain breakages if the major -version number is not increased.

For bundles implementing the API, this default does not work well, since -from their point of view an externally visible change in fact constitutes -a breakage, because the implementation is not complete. So if a bundle -implements a package a manually crafted import version should be defined -which includes the export version of the defining bundle but excludes the -next minor version.

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)
-

- - -

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).

Future

Recent versions of the BND library support automatic differntiation between -use and implementation of API and to set the import version ranges -accordingly. See Bnd Experimental - for details. Unfortunately the current Maven Bundle Plugin version does -not support updating to the most recent BND library versions due to -incompatibilities.

References

Version Numbers - -- The mail thread discussing version numbering -On Version Numbers - -- Blog about version numbers -Version Numbering - -- An Eclipse paper on assigning version numbers. Very good read. -Semantic Versioning - -- An OSGi Alliance paper on semantic versioning. -Bnd Experimental - -- Experimental extensions to the BND library; unfortunately these -extensions are not yet usable with Maven Bundle Plugin 2.1.0 due to API -changes in the BND library not supported by the plugin.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/web-console-extensions.html ============================================================================== --- websites/staging/sling/trunk/content/web-console-extensions.html (original) +++ websites/staging/sling/trunk/content/web-console-extensions.html Sun Apr 22 17:09:56 2012 @@ -79,64 +79,10 @@

- (TODO: breadcrumb here) +Home

Web Console Extensions

The Apache Sling project provides two extensions to the Apache Felix Web Console - (in addition to a number of plugins, of course):

{toc:minLevel=2|maxLevel=2}

Branding (org.apache.sling.extensions.webconsolebranding)

The Apache Sling Web Console Branding provided by Apache Sling is currently -just for the product logo displayed in the upper right corner of the Web -Console and some titles and strings.

This bundle will attach as a fragment bundle to the Apache Felix Web -Console bundle. To enable it after installation into a running system, you -might have to refresh the package imports of the Apache Felix Web Console -bundle. If you install using the Apache Felix Web Console bundle -installation functionality, this will be taken care of by the Web Console.

h2. Security Provider -(org.apache.sling.extensions.webconsolesecurityprovider)

The Apache Sling Web Console Security Provider implements the Apache Felix -Web Console WebConsoleSecurityProvider interface authenticating Web -Console users against the JCR repository. Each username and password -presented is used to login to the JCR repository and to check the -respective session.

Ensure the username and password can be used to login to the default -workspace. If not, access is denied
If the username presented is one of the user names configured with the -users configuration property, access is granted.
Otherwise if the user is a (direct or indirect) member of one of the -groups configured with the groups configuration property, access is -granted.

Access is denied if the username and password cannot be used to login to -the default workspace or if the user is neither one of the configured -allowed users nor in any of the configured groups.

Configuration

The Security Provider is configured with configuration with PID -org.apache.sling.extensions.webconsolesecurityprovider.internal.SlingWebConsoleSecurityProvider -supporting the following properties:

- - - - -

Property	Type	Default Value	Description -
users	String, {{String[](.html) -}} or Vector	admin	The list of users granted access to the -Web Console
groups	String, {{String[](.html) -}} or Vector	---	The list of groups whose (direct or -indirect) members are granted access to the Web Console

+ -

Note, that while the default value explicitly grants the admin user to -access the Web Console it is suggested that system administrators define a -special group and assign users with Web Console access to this group.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/wiki.html ============================================================================== --- websites/staging/sling/trunk/content/wiki.html (original) +++ websites/staging/sling/trunk/content/wiki.html Sun Apr 22 17:09:56 2012 @@ -79,36 +79,10 @@

- (TODO: breadcrumb here) -

wiki

Apache Sling Website

{tip:title=Use Generated Pages} -The Apache Sling project uses a Confluence space for documentation purposes -and to generate the static Sling web site. You are currently looking at the -source wiki. End users should generally use the static, generated pages, at -http://incubator.apache.org/sling since the wiki is typically only -necessary for editing content. Below you'll find an overview of the main -menu, all pages in this wiki as well as a list of recently modified pages. -{tip}

{section} -{column:width=50%} -

- -

{include:navigation} -

Site map

{children:page=SLINGxSITE:|all=true} -{column} -{section}

+Home

+ +

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/wrap-or-decorate-resources.html ============================================================================== --- websites/staging/sling/trunk/content/wrap-or-decorate-resources.html (original) +++ websites/staging/sling/trunk/content/wrap-or-decorate-resources.html Sun Apr 22 17:09:56 2012 @@ -79,51 +79,10 @@

- (TODO: breadcrumb here) +Home

Wrap or Decorate Resources

Service to wrap resources

Introduction

The Sling API provides an easy way to wrap or decorate a resource before -returning. Use cases for this could for example be - overwrite resource type/resource super type (for example based on the -resource path) - add metadata

To add a resource decorator just register one or more services which -implement the interface ResourceDecorator

interface ResourceDecorator {
-    Resource decorate(Resource)
+   
 
-    @Deprecated
-    Resource decorate(Resource, HttpServletRequest)
-}
-

- - -

The registered decorators will be called from the resource resolver for -each resource returned. -If the service decorates the resource it should return the new resource. If -the service does not want to decorate the resource, it should return the -original resource or null.

The two-argument {decorate} method will not be invoked, starting with -version 2.1.0 of the JCR Resource bundle. Implementors of this interface -targeting both newer and older versions of this bundle are advised to -implement this method with:

    public Resource decorate(Resource resource, HttpServletRequest request)
-

- - -

{ - return this.decorate(resource); - }

And use some other method (e.g. a {ThreadLocal}) to obtain the current -request if necessary.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/xslt-processing-pipeline.html ============================================================================== --- websites/staging/sling/trunk/content/xslt-processing-pipeline.html (original) +++ websites/staging/sling/trunk/content/xslt-processing-pipeline.html Sun Apr 22 17:09:56 2012 @@ -79,12 +79,10 @@

- (TODO: breadcrumb here) -

XSLT Processing Pipeline

- +Home

+ +

Option	Argument	Description
start	--	Open a TCP/IP server socket when starting Sling. Uses -option -j to define the local socket address.
status	--	Check whether a (remote) Sling application is running. -Uses option -j to define the address of the Sling instance to check. -Note, that the Sling application terminates after checking for the (remote) -Sling status.
stop	--	Stop a (remote) Sling application is running. Uses option --j to define the address of the Sling instance to stop. Note, that the -Sling application terminates after stopping the (remote) Sling instance.
-c	slinghome	The directory in which Sling locates its initial -configuration file sling.properties and where files of Sling itself -such as the Apache Felix bundle archive or the JCR repository files are -stored. This defaults to the sling folder in the current working -directory. This is the value which is commonly refered to as -$\{sling.home}. -
-l	loglevel	Sets the initial loglevel as an integer in the range -0 to 4 or as one of the well known level strings ERROR, WARN, -INFO, or DEBUG. This option overwrites the -org.apache.sling.osg.log.level setting the sling.properties file. -The default is INFO.
-f	logfile	The log file to use or - to log to standard out. -This option overwrites the org.apache.sling.osg.log.file setting the -sling.properties file. The default is -$\{sling.home}/logs/error.log.
-a	address	The interfact to bind to (use 0.0.0.0 for any). This -option is not implemented yet.
-p	port	The port to listen (default 8080) to handle HTTP -requests. This option overwrites the org.osgi.service.http.port setting -the sling.properties file.
-j	[ host ":" ](-host-":"-.html) - port	The socket address to listen on for control connections (start -or to use as the remote endpoint for the control connection (status and -stop. If this parameter has no arguments or is not specified, the -address defaults to port 63000 on localhost/127.0.0.1. If only the port is -specified localhost/127.0.0.1 is used as the host part of the address.
-h	--	Prints a simple usage message listing all available command -line options.

Servlet Context	Default sling.home
_root_	sling/\_
/sling	sling/\_sling
/sling/instance1	sling/\_sling\_instance1

Servlet Context	Default sling.home
_root_	/var/sling/\_
/sling	/var/sling/\_sling
/sling/instance1	/var/sling/\_sling\_instance1

The Sling Launchpad

The Sling Launchpad

Sling Home

Command Line Options

Security Implication

Servlet Parameters

sling.properties

Components

Launchpad Base

Launchpad Bundles

Launchpad App and Launchpad WebApp

URL decomposition

URL decomposition

Version Policy

DRAFT Version Policy

Introduction

Version Number Syntax

Evolution of Exported Package Versions

Evolution of Bundle Versions

Examples

Pure API Bundle

Implementation Bundle providing API

Pure Implementation Bundle

Importing Packages

References

Web Console Extensions

Web Console Extensions

Branding (org.apache.sling.extensions.webconsolebranding)

Configuration

wiki

Apache Sling Website

Menu

Recently updated pages

Site map

Wrap or Decorate Resources

Service to wrap resources

Introduction

XSLT Processing Pipeline