You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by fm...@apache.org on 2012/05/22 10:25:22 UTC
svn commit: r1341347 [10/16] - in /sling/site/trunk: ./ content/
content/tutorials-how-tos/
Modified: sling/site/trunk/content/openid-authenticationhandler.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/openid-authenticationhandler.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/openid-authenticationhandler.mdtext (original)
+++ sling/site/trunk/content/openid-authenticationhandler.mdtext Tue May 22 08:25:18 2012
@@ -1,298 +1,133 @@
Title: OpenID AuthenticationHandler
-<a name="OpenIDAuthenticationHandler-OpenIDAuthenticationHandler"></a>
+
# OpenID AuthenticationHandler
-{toc:type=flat|separator=pipe|minLevel=2|maxLevel=3}
+[TOC]
+
+The OpenID Authentication Handler supports authentication of request users using the [OpenID]({{ refs.http://www.openid.net.path }}) authentication protocol. If the user has successfully authenticated with his OpenID provider a signed OpenID identity is further used to identify the user.
+
+Since generally an OpenID identity is an URL and URLs may not be used as JCR user names, an association mechanism is used by the OpenID authentication handler to associate an OpenID identity with an existing JCR user: The OpenID identity URL is set as the value of a JCR user property. When a user authenticates with his OpenID identity the matching user searched for by looking for a match in this property.
-The OpenID Authentication Handler supports authentication of request users
-using the [OpenID](http://www.openid.net)
- authentication protocol. If the user has successfully authenticated with
-his OpenID provider a signed OpenID identity is further used to identify
-the user.
-
-Since generally an OpenID identity is an URL and URLs may not be used as
-JCR user names, an association mechanism is used by the OpenID
-authentication handler to associate an OpenID identity with an existing JCR
-user: The OpenID identity URL is set as the value of a JCR user property.
-When a user authenticates with his OpenID identity the matching user
-searched for by looking for a match in this property.
-
-_NOTE:_ This association currently only works with Jackrabbit (or
-Jackrabbit based repositories) because user management is not part of the
-JCR 2 specification and the OpenID authentication handler uses the
-Jackrabbit *UserManager* to find users by a user property value.
+*NOTE:* This association currently only works with Jackrabbit (or Jackrabbit based repositories) because user management is not part of the JCR 2 specification and the OpenID authentication handler uses the Jackrabbit `UserManager` to find users by a user property value.
-The OpenID Authentication Handler is maintained in the [Sling SVN](http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/openid/)
+The OpenID Authentication Handler is maintained in the [Sling SVN]({{ refs.http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/openid/.path }})
-<a name="OpenIDAuthenticationHandler-CredentialsExtraction"></a>
### Credentials Extraction
-Theoretically each request with the *openid_identifier* request parameter
-set may initiate an OpenID authentication process which involves resolving
-the OpenID provider for the identifier and subsequently authentication with
-the provider authorizing the Sling instance to use the OpenID identity.
-
-This initiation, though, is not possible if the request already contains a
-valid and validated OpenID identifier either set as a request attribute or
-set in the HTTP Session or the OpenID cookie. In these situations, the
-current association of a client with an OpenID identity must first be
-removed by logging out, e.g. by requesting */system/sling/logout.html*
-which causes the current OpenID user data to be removed by either removing
-it from the HTTP Session or by clearing the OpenID cookie.
+Theoretically each request with the `openid_identifier` request parameter set may initiate an OpenID authentication process which involves resolving the OpenID provider for the identifier and subsequently authentication with the provider authorizing the Sling instance to use the OpenID identity.
+
+This initiation, though, is not possible if the request already contains a valid and validated OpenID identifier either set as a request attribute or set in the HTTP Session or the OpenID cookie. In these situations, the current association of a client with an OpenID identity must first be removed by logging out, e.g. by requesting `/system/sling/logout.html` which causes the current OpenID user data to be removed by either removing it from the HTTP Session or by clearing the OpenID cookie.
-<a name="OpenIDAuthenticationHandler-Phase1:FormSubmission"></a>
### Phase 1: Form Submission
-Requesting an OpenID identifier is initiated by the Sling Authenticator
-deciding, that authentication is actually required to process a request and
-the OpenID Authentication Handler being selected to request credentials
-with.
-
-In this case the OpenID authenticator causes a form to be rendered by
-redirecting the client to the URL indicated by the *form.login.form*
-configuration parameter. This redirection request may accompanied by the
-following parameters:
-
-<table>
-<tr><th> Request Parameter </th><th> Description </th></tr>
-<tr><td> *resource* </td><td> The location to which the user initially requested access
-and that caused the *requestCredentials* method to be called. This may
-not be set (or be set to an empty string). </td></tr>
-<tr><td> *j_reason* </td><td> The reason why an earlier attempt at authentication with
-the OpenID authentication handler failed. This request parameter is only
-set if the same named request attribute has been set by the
-*extractCredentials* or the *authenticationFailed* method. The value of
-the parameter is the name of one of the *OpenIDFailure* constants. </td></tr>
-<tr><td> *j_openid_identity* </td><td> The OpenID identity which could not successfully
-be associated with an existing JCR user. This request parameter is only set
-if the *authenticationFailed* method has been called due to inability to
-associate an existing and validated OpenID identity with an existing JCR
-user. </td></tr>
-</table>
-
-The OpenID Authentication handlers supports the following request
-parameters submitted by the HTML form:
-
-* *openid_identifier* -- OpenID Claimed Identifier. This may be any
-actual OpenID identity URL or the URL of OpenID Provider such as
-https://www.google.com/accounts/o8/id, https://me.yahoo.com, or
-https://www.myopenid.com.
-* *sling:authRequestLogin* -- This request parameter is recommended to be
-set with a hidden field to the value _OpenID_ to ensure the request is
-handled by the OpenID Authentication Handler.
-* *resource* -- The *resource* request parameter should be sent back to
-ensure the user is finally redirected to requested target resource after
-successful authentication. If this request parameter is not set, or is set
-to an empty string, it is assumed to be the request context root path.
+Requesting an OpenID identifier is initiated by the Sling Authenticator deciding, that authentication is actually required to process a request and the OpenID Authentication Handler being selected to request credentials with.
+
+In this case the OpenID authenticator causes a form to be rendered by redirecting the client to the URL indicated by the `form.login.form` configuration parameter. This redirection request may accompanied by the following parameters:
-The OpenID Authentication Handler provides a default login form registered
-at */system/sling/openid/login*.
+| Request Parameter | Description |
+|--|--|
+| `resource` | The location to which the user initially requested access and that caused the `requestCredentials` method to be called. This may not be set (or be set to an empty string). |
+| `j_reason` | The reason why an earlier attempt at authentication with the OpenID authentication handler failed. This request parameter is only set if the same named request attribute has been set by the `extractCredentials` or the `authenticationFailed` method. The value of the parameter is the name of one of the `OpenIDFailure` constants. |
+| `j*openid*identity` | The OpenID identity which could not successfully be associated with an existing JCR user. This request parameter is only set if the `authenticationFailed` method has been called due to inability to associate an existing and validated OpenID identity with an existing JCR user. |
+
+The OpenID Authentication handlers supports the following request parameters submitted by the HTML form:
+
+* `openid_identifier` -- OpenID Claimed Identifier. This may be any actual OpenID identity URL or the URL of OpenID Provider such as https://www.google.com/accounts/o8/id, https://me.yahoo.com, or https://www.myopenid.com.
+* `sling:authRequestLogin` -- This request parameter is recommended to be set with a hidden field to the value *OpenID* to ensure the request is handled by the OpenID Authentication Handler.
+* `resource` -- The `resource` request parameter should be sent back to ensure the user is finally redirected to requested target resource after successful authentication. If this request parameter is not set, or is set to an empty string, it is assumed to be the request context root path.
+
+The OpenID Authentication Handler provides a default login form registered at `/system/sling/openid/login`.
-<a name="OpenIDAuthenticationHandler-Configuration"></a>
### Configuration
-The OpenID AuthenticationHandler is configured with configuration provided
-by the OSGi Configuration Admin Service using the
-*org.apache.sling.openidauth.OpenIdAuthenticationHandler* service PID.
-
-<table>
-<tr><th> Parameter </th><th> Default </th><th> Description </th></tr>
-<tr><td> *path* </td><td> -- </td><td> Repository path for which this authentication handler
-should be used by Sling. If this is empty, the authentication handler will
-be disabled. </td></tr>
-<tr><td> *openid.login.form* </td><td> */system/sling/openid/login* </td><td> This should
-provide a way to capture the user's OpenID identifier. This is not the
-OpenID Provider's login page, however, it does not have to be a local URL.
-If it is a local Sling URL, it must be accessible by the anonymous user.
-The user is HTTP Redirect'ed to this URL. This page should POST back the
-user's OpenID identifier (as named by the "OpenID identifier form field"
-property) to the originally requested URL set in the "resource" request
-parameter. </td></tr>
-<tr><td> *openid.login.identifier* </td><td> *openid_identifier* </td><td> The name of the
-form parameter that provides the user's OpenID identifier. By convention
-this is *openid_identifier*. Only change this if you have a very good
-reason to do so. </td></tr>
-<tr><td> *openid.external.url.prefix* </td><td> -- </td><td> The prefix of URLs generated for
-the *ReturnTo* and *TrustRoot* properties of the OpenID request to the
-OpenID provider. Thus this URL prefix should bring back the authenticated
-user to this Sling instance. Configuring this property is usually necessary
-when running Sling behind a proxy (like Apache) since proxy mapping is not
-performed on the OpenID ReturnTo and TrustRoot URLs as they are sent to the
-OpenID Provider as form parameters. If this property is empty, the URLs
-are generated using the hostname found in the original request.</td></tr>
-<tr><td> *openid.use.cookie* </td><td> *true* </td><td> Whether to use a regular Cookie or an
-HTTP Session to cache the OpenID authentication details. By default a
-regular cookie is used to prevent use of HTTP Sessions. </td></tr>
-<tr><td> *openid.cookie.domain* </td><td> -- </td><td> Domain of cookie used to persist
-authentication. This defaults to the host name of the Sling server but may
-be set to a different value to share the cookie amongst a server farm or if
-the server is running behind a proxy. Only used if 'Use Cookie' is checked.
-</td></tr>
-<tr><td> *openid.cookie.name* </td><td> *sling.openid* </td><td> Name of cookie used to
-persist authentication. Only used if 'Use Cookie' is checked. </td></tr>
-<tr><td> *openid.cookie.secret.key* </td><td> *secret* </td><td> Secret key used to create a
-signature of the cookie value to prevent tampering. Only used if 'Use
-Cookie' is true. </td></tr>
-<tr><td> *openid.user.attr* </td><td> *openid.user* </td><td> Name of the JCR
-SimpleCredentials attribute to to set with the OpenID User data. This
-attribute is used by the OpenID LoginModule to validate the OpenID user
-authentication data. </td></tr>
-<tr><td> *openid.property.identity* </td><td> *openid.identity* </td><td> The name of the JCR
-User attribute listing one or more OpenID Identity URLs with which a user
-is associated. The property may be a multi- or single-valued. To resolve a
-JCR user ID from an OpenID identity a user is searched who lists the
-identity in this property. </td></tr>
-</table>
+The OpenID AuthenticationHandler is configured with configuration provided by the OSGi Configuration Admin Service using the `org.apache.sling.openidauth.OpenIdAuthenticationHandler` service PID.
+
+| Parameter | Default | Description |
+|--|--|--|
+| `path` | -- | Repository path for which this authentication handler should be used by Sling. If this is empty, the authentication handler will be disabled. |
+| `openid.login.form` | `/system/sling/openid/login` | This should provide a way to capture the user's OpenID identifier. This is not the OpenID Provider's login page, however, it does not have to be a local URL. If it is a local Sling URL, it must be accessible by the anonymous user. The user is HTTP Redirect'ed to this URL. This page should POST back the user's OpenID identifier (as named by the "OpenID identifier form field" property) to the originally requested URL set in the "resource" request parameter. |
+| `openid.login.identifier` | `openid*identifier` | The name of the form parameter that provides the user's OpenID identifier. By convention this is `openid*identifier`. Only change this if you have a very good reason to do so. |
+| `openid.external.url.prefix` | -- | The prefix of URLs generated for the `ReturnTo` and `TrustRoot` properties of the OpenID request to the OpenID provider. Thus this URL prefix should bring back the authenticated user to this Sling instance. Configuring this property is usually necessary when running Sling behind a proxy (like Apache) since proxy mapping is not performed on the OpenID ReturnTo and TrustRoot URLs as they are sent to the OpenID Provider as form parameters. If this property is empty, the URLs are generated using the hostname found in the original request.|
+| `openid.use.cookie` | `true` | Whether to use a regular Cookie or an HTTP Session to cache the OpenID authentication details. By default a regular cookie is used to prevent use of HTTP Sessions. |
+| `openid.cookie.domain` | -- | Domain of cookie used to persist authentication. This defaults to the host name of the Sling server but may be set to a different value to share the cookie amongst a server farm or if the server is running behind a proxy. Only used if 'Use Cookie' is checked. |
+| `openid.cookie.name` | `sling.openid` | Name of cookie used to persist authentication. Only used if 'Use Cookie' is checked. |
+| `openid.cookie.secret.key` | `secret` | Secret key used to create a signature of the cookie value to prevent tampering. Only used if 'Use Cookie' is true. |
+| `openid.user.attr` | `openid.user` | Name of the JCR SimpleCredentials attribute to to set with the OpenID User data. This attribute is used by the OpenID LoginModule to validate the OpenID user authentication data. |
+| `openid.property.identity` | `openid.identity` | The name of the JCR User attribute listing one or more OpenID Identity URLs with which a user is associated. The property may be a multi- or single-valued. To resolve a JCR user ID from an OpenID identity a user is searched who lists the identity in this property. |
-<a name="OpenIDAuthenticationHandler-AuthenticationHandlerimplementation"></a>
### AuthenticationHandler implementation
-<a name="OpenIDAuthenticationHandler-extractCredentials"></a>
#### extractCredentials
-To extract authentication information from the request, the Sling OpenID
-Authentication handler considers the following information in order:
+To extract authentication information from the request, the Sling OpenID Authentication handler considers the following information in order:
+
+1. The OpenID credentials cookie or OpenID User data in the HTTP Session (depending on the `openid.use.cookie` configuration)
+1. Otherwise the `openid_identifier` request parameter (or a different request parameter depending on the `openid.login.identifier` configuration)
-1. The OpenID credentials cookie or OpenID User data in the HTTP Session
-(depending on the *openid.use.cookie* configuration)
-1. Otherwise the *openid_identifier* request parameter (or a different
-request parameter depending on the *openid.login.identifier*
-configuration)
-
-If the OpenID credentials already exist in the request, they are validated
-and returned if valid
-
-If the existing credentials fail to validate, authentication failure is
-assumed and the credentials are removed from the request, either by
-clearing the OpenID cookie or by removing the OpenID User data from the
-HTTP Session.
-
-If no OpenID credentials are found in the request, the request parameter is
-considered and if set is used to resolve the actual OpenID identity of the
-user. This involves redirecting the client to the OpenID provider resolved
-from the OpenID identifier supplied.
-
-If the supplied OpenID identifier fails to resolve to an OpenID provider or
-if the identifier fails to be resolved to a validated OpenID identity,
-authentication fails.
+If the OpenID credentials already exist in the request, they are validated and returned if valid
+
+If the existing credentials fail to validate, authentication failure is assumed and the credentials are removed from the request, either by clearing the OpenID cookie or by removing the OpenID User data from the HTTP Session.
+
+If no OpenID credentials are found in the request, the request parameter is considered and if set is used to resolve the actual OpenID identity of the user. This involves redirecting the client to the OpenID provider resolved from the OpenID identifier supplied.
+
+If the supplied OpenID identifier fails to resolve to an OpenID provider or if the identifier fails to be resolved to a validated OpenID identity, authentication fails.
-<a name="OpenIDAuthenticationHandler-requestCredentials"></a>
#### requestCredentials
-If the *sling:authRequestLogin* parameter is set to a value other than
-*OpenID* this method immediately returns *false*.
+If the `sling:authRequestLogin` parameter is set to a value other than `OpenID` this method immediately returns `false`.
-If the parameter is not set or is set to *OpenID* this method continues
-with first invalidating any cached OpenID credentials (same as
-*dropCredentials* does) and then redirecting the client to the login form
-configured with the *openid.login.form* configuration property. The
-redirect is provided with up to three request parameters:
-
-<table>
-<tr><th> Request Parameter </th><th> Description </th></tr>
-<tr><td> *resource* </td><td> The location to which the user initially requested access
-and that caused the *requestCredentials* method to be called. </td></tr>
-<tr><td> *j_reason* </td><td> The reason why an earlier attempt at authentication with
-the OpenID authentication handler failed. This request parameter is only
-set if the same named request attribute has been set by the
-*extractCredentials* or the *authenticationFailed* method. The value of
-the parameter is the name of one of the *OpenIDFailure* constants. </td></tr>
-<tr><td> *j_openid_identity* </td><td> The OpenID identity which could not successfully
-be associated with an existing JCR user. This request parameter is only set
-if the *authenticationFailed* method has been called due to inability to
-associate an existing and validated OpenID identity with an existing JCR
-user. </td></tr>
-</table>
+If the parameter is not set or is set to `OpenID` this method continues with first invalidating any cached OpenID credentials (same as `dropCredentials` does) and then redirecting the client to the login form configured with the `openid.login.form` configuration property. The redirect is provided with up to three request parameters:
+
+| Request Parameter | Description |
+|--|--|
+| `resource` | The location to which the user initially requested access and that caused the `requestCredentials` method to be called. |
+| `j_reason` | The reason why an earlier attempt at authentication with the OpenID authentication handler failed. This request parameter is only set if the same named request attribute has been set by the `extractCredentials` or the `authenticationFailed` method. The value of the parameter is the name of one of the `OpenIDFailure` constants. |
+| `j*openid*identity` | The OpenID identity which could not successfully be associated with an existing JCR user. This request parameter is only set if the `authenticationFailed` method has been called due to inability to associate an existing and validated OpenID identity with an existing JCR user. |
-<a name="OpenIDAuthenticationHandler-dropCredentials"></a>
#### dropCredentials
-Invalidates the OpenID identity currently stored with the request. This
-means to either remove the OpenID cookie or to remove the OpenID
-information from the HTTP Session. This method does not write to the
-response (except setting the *Set-Cookie* header to remove the OpenID
-cookie if required) and does not commit the response.
+Invalidates the OpenID identity currently stored with the request. This means to either remove the OpenID cookie or to remove the OpenID information from the HTTP Session. This method does not write to the response (except setting the `Set-Cookie` header to remove the OpenID cookie if required) and does not commit the response.
-<a name="OpenIDAuthenticationHandler-AuthenticationFeedbackHandlerimplementation"></a>
### AuthenticationFeedbackHandler implementation
-<a name="OpenIDAuthenticationHandler-authenticationFailed"></a>
#### authenticationFailed
-This method is called, if the Credentials provided by the Authentication
-Handler could not be validated by the Jackrabbit authentication
-infrastructure. One cause may be that the integration with Jackrabbit has
-not been completed (see _Integration with Jackrabbit_ below). Another, more
-probably cause, is that the validated OpenID identifier cannot be
-associated with an existing JCR user.
-
-The OpenID Authentication Handler implementation of the
-*authenticationFailed* method sets the *j_reason* request attribute to
-*OpenIDFailure.REPOSITORY* and sets the *j_openid_identity* request
-attribute to the OpenID identity of the authenticated user.
-
-A login form provider may wish to act upon this situation and provide a
-login form to the user to allow to his OpenID identity with an existing JCR
-user.
-
-In addition, the current OpenID identity is invalidated thus the cached
-OpenID information is removed from the HTTP Session or the OpenID cookie is
-cleaned. This will allow the user to present a different OpenID identifier
-to retry or it will require the OpenID identity to be revalidated with the
-OpenID provider if the identity is associated with a JCR user.
+This method is called, if the Credentials provided by the Authentication Handler could not be validated by the Jackrabbit authentication infrastructure. One cause may be that the integration with Jackrabbit has not been completed (see *Integration with Jackrabbit* below). Another, more probably cause, is that the validated OpenID identifier cannot be associated with an existing JCR user.
+
+The OpenID Authentication Handler implementation of the `authenticationFailed` method sets the `j*reason` request attribute to `OpenIDFailure.REPOSITORY` and sets the `j*openid_identity` request attribute to the OpenID identity of the authenticated user.
+
+A login form provider may wish to act upon this situation and provide a login form to the user to allow to his OpenID identity with an existing JCR user.
+
+In addition, the current OpenID identity is invalidated thus the cached OpenID information is removed from the HTTP Session or the OpenID cookie is cleaned. This will allow the user to present a different OpenID identifier to retry or it will require the OpenID identity to be revalidated with the OpenID provider if the identity is associated with a JCR user.
-<a name="OpenIDAuthenticationHandler-authenticationSucceeded"></a>
#### authenticationSucceeded
-The OpenID Authentication Handler implementation of the
-*authenticationSucceeded* method just calls the
-*DefaultAuthenticationFeedbackHandler.handleRedirect* method to redirect
-the user to the initially requested location.
+The OpenID Authentication Handler implementation of the `authenticationSucceeded` method just calls the `DefaultAuthenticationFeedbackHandler.handleRedirect` method to redirect the user to the initially requested location.
-<a name="OpenIDAuthenticationHandler-IntegrationwithJackrabbit"></a>
### Integration with Jackrabbit
-The OpenID authentication handler can be integrated in two ways into the
-Jackrabbit authentication mechanism which is based on JAAS *LoginModule*.
-One integration is by means of a *LoginModulePlugin* which plugs into the
-extensible *LoginModule* architecture supported by the Sling Jackrabbit
-Embedded Repository bundle.
-
-The other integration option is the *trusted_credentials_attribute*
-mechanism supported by the Jackrabbit *DefaultLoginModule*. By setting
-the *trusted_credentials_attribute* parameter of the Jackrabbit
-*DefaultLoginModule* and the *openid.user.attr* configuration property
-of the OpenID Authentication Handler to the same value, the existence of an
-attribute of that name in the *SimpleCredentials* instance provided to
-the *Repository.login* method signals pre-authenticated credentials,
-which need not be further checked by the *DefaultLoginModule*.
+The OpenID authentication handler can be integrated in two ways into the Jackrabbit authentication mechanism which is based on JAAS `LoginModule`. One integration is by means of a `LoginModulePlugin` which plugs into the extensible `LoginModule` architecture supported by the Sling Jackrabbit Embedded Repository bundle.
+
+The other integration option is the `trusted*credentials*attribute` mechanism supported by the Jackrabbit `DefaultLoginModule`. By setting the `trusted*credentials*attribute` parameter of the Jackrabbit `DefaultLoginModule` and the `openid.user.attr` configuration property of the OpenID Authentication Handler to the same value, the existence of an attribute of that name in the `SimpleCredentials` instance provided to the `Repository.login` method signals pre-authenticated credentials, which need not be further checked by the `DefaultLoginModule`.
-<a name="OpenIDAuthenticationHandler-SecurityConsiderations"></a>
### Security Considerations
OpenIDAuthentication has some limitations in terms of security:
-1. User name and password are transmitted in plain text in the initial form
-submission.
-1. The Cookie used to provide the authentication state or the HTTP Session
-ID may be stolen.
-1. When using the *trusted_credentials_attribute* mechanism, any intruder
-knowing the attribute name may log into the repository as any existing JCR
-user. The better option is to be based on the *LoginModulePlugin*
-mechanism.
-
-To prevent eavesdroppers from sniffing the credentials or stealing the
-Cookie a secure transport layer should be used such as TLS/SSL, VPN or
-IPSec.
+1. User name and password are transmitted in plain text in the initial form submission.
+1. The Cookie used to provide the authentication state or the HTTP Session ID may be stolen.
+1. When using the `trusted*credentials*attribute` mechanism, any intruder knowing the attribute name may log into the repository as any existing JCR user. The better option is to be based on the `LoginModulePlugin` mechanism.
+
+To prevent eavesdroppers from sniffing the credentials or stealing the Cookie a secure transport layer should be used such as TLS/SSL, VPN or IPSec.
Modified: sling/site/trunk/content/osgi-installer.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/osgi-installer.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/osgi-installer.mdtext (original)
+++ sling/site/trunk/content/osgi-installer.mdtext Tue May 22 08:25:18 2012
@@ -1,103 +1,45 @@
Title: OSGi Installer
-<a name="OSGiInstaller-Overview"></a>
+
# Overview
-The OSGi installer is a central service for handling installs, updates and
-uninstall of "artifacts". By default, the installer supports bundles and
-has an extension for handling configurations for the OSGi configuration
-admin.
+The OSGi installer is a central service for handling installs, updates and uninstall of "artifacts". By default, the installer supports bundles and has an extension for handling configurations for the OSGi configuration admin.
!Slide14.jpg|border=1!
-The OSGi installer itself is "just" the central service managing the tasks
-and states of the artifacts. The artifacts can be provided through various
-providers, e.g. through a file system provider reading artifacts from
-configured directories or the jcr provider reading artifacts from a JCR
-repository.
-
-A provider is just scanning for artifacts and their removal. It informs the
-OSGi installer about new artifacts and removed artifacts. The provider
-itself has usually no knowledge about the contents of an artifact. It does
-not know about bundles, configurations etc.
-
-As the OSGi installer itself is not performing the actual install, update
-or removal of an artifact, its possible to install transformers and
-installer factories. A transformer inspects the artifacts and tries to
-detect its type. By default, detecting of bundles and configurations is
-supported. The final service is an installer factory creating the actual
-task, like install this bundle, update that bundle etc.
+The OSGi installer itself is "just" the central service managing the tasks and states of the artifacts. The artifacts can be provided through various providers, e.g. through a file system provider reading artifacts from configured directories or the jcr provider reading artifacts from a JCR repository.
+
+A provider is just scanning for artifacts and their removal. It informs the OSGi installer about new artifacts and removed artifacts. The provider itself has usually no knowledge about the contents of an artifact. It does not know about bundles, configurations etc.
+
+As the OSGi installer itself is not performing the actual install, update or removal of an artifact, its possible to install transformers and installer factories. A transformer inspects the artifacts and tries to detect its type. By default, detecting of bundles and configurations is supported. The final service is an installer factory creating the actual task, like install this bundle, update that bundle etc.
-It's possible to add own providers, transformers and installer factories to
-support custom scenarios.
+It's possible to add own providers, transformers and installer factories to support custom scenarios.
-<a name="OSGiInstaller-ArtifactHandling"></a>
## Artifact Handling
-Once an artifact is detected by a transformer, it gets a unique id. By
-default a bundle gets the symbolic name as the unique identifier and a
-configuration the PID.
-In addition to this id, an artifact gets a priority information from the
-provider. The priority is used if an artifact with the same id is provided
-several times from different locations. For example if a file system
-provider is scanning two directories and an artifact with the same id (like
-a configuration) is added to both directories, one should have precedence
-over the other. This is handled by the priority.
-
-Artifacts with the same unique id are grouped and then sorted by priority
-and maybe other artifact dependent metadata like the bundle version. Only
-the first artifact in this sorted group is tried to be applied!
+Once an artifact is detected by a transformer, it gets a unique id. By default a bundle gets the symbolic name as the unique identifier and a configuration the PID.
+In addition to this id, an artifact gets a priority information from the provider. The priority is used if an artifact with the same id is provided several times from different locations. For example if a file system provider is scanning two directories and an artifact with the same id (like a configuration) is added to both directories, one should have precedence over the other. This is handled by the priority.
+
+Artifacts with the same unique id are grouped and then sorted by priority and maybe other artifact dependent metadata like the bundle version. Only the first artifact in this sorted group is tried to be applied!
-<a name="OSGiInstaller-BundleHandling"></a>
## Bundle Handling
-In general, the OSGi installer always tries to install the highest version
-of a bundle if several bundles with the same symbolic name are provided. In
-this case higher version wins over priority.
-If an installed bundle is removed by a provider, for example deleted in the
-repository, the OSGi installer uninstall the bundle.
-If a bundle is removed from a provider which is currently not installed,
-this has no effect at all.
-If an installed bundle is removed and another version of this bundle is
-provided (a lower version), than this one is installed instead. This is
-basically a downgrade of the bundle.
-If a bundle is installed and a higher version is provided, an upgrade is
-performed.
-If an installed bundle is managed via any other OSGi tooling, like
-uninstalling it through the web console, the OSGi installer does no action
-at all!
-
-If a failure occurs during bundle installation or update, the OSGi
-installer will retry this as soon as another bundle has been installed. The
-common use case is an application installation with several bundles where
-one bundle depends on another. As they are installed in arbitrary order,
-this mechanism ensures that in the end all bundles are properly wired and
-installed.
+In general, the OSGi installer always tries to install the highest version of a bundle if several bundles with the same symbolic name are provided. In this case higher version wins over priority.
+If an installed bundle is removed by a provider, for example deleted in the repository, the OSGi installer uninstall the bundle.
+If a bundle is removed from a provider which is currently not installed, this has no effect at all.
+If an installed bundle is removed and another version of this bundle is provided (a lower version), than this one is installed instead. This is basically a downgrade of the bundle.
+If a bundle is installed and a higher version is provided, an upgrade is performed.
+If an installed bundle is managed via any other OSGi tooling, like uninstalling it through the web console, the OSGi installer does no action at all!
+
+If a failure occurs during bundle installation or update, the OSGi installer will retry this as soon as another bundle has been installed. The common use case is an application installation with several bundles where one bundle depends on another. As they are installed in arbitrary order, this mechanism ensures that in the end all bundles are properly wired and installed.
-When all artifacts have been processed (either install, update or delete),
-a package refresh is automatically called.
+When all artifacts have been processed (either install, update or delete), a package refresh is automatically called.
-<a name="OSGiInstaller-VersionsandSnapshots"></a>
### Versions and Snapshots
-The OSGi installer asumes that a symbolic name and version (not a snapshot
-version) uniquely identifies a bundle. Obviously this is a common
-development requirement that a released version of an artifact never
-changes over time. Therefore, once a bundle with a specific version is
-installed, it will not be reinstalled if the corresponding artifact
-changes. For example, if bundle A with version 1.0 is put into the JCR
-repository, it gets installed. If now this jar in the repository is
-overwritten either with the same contents or with a different one, and this
-new artifact has again A as the symbolic name and version set to 1.0,
-nothing will happen as this exact bundle is already installed.
-
-During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT
-(using the Maven convention). If a bundle with a snapshot version is
-changed, it gets updated by the OSGI installer.
+The OSGi installer asumes that a symbolic name and version (not a snapshot version) uniquely identifies a bundle. Obviously this is a common development requirement that a released version of an artifact never changes over time. Therefore, once a bundle with a specific version is installed, it will not be reinstalled if the corresponding artifact changes. For example, if bundle A with version 1.0 is put into the JCR repository, it gets installed. If now this jar in the repository is overwritten either with the same contents or with a different one, and this new artifact has again A as the symbolic name and version set to 1.0, nothing will happen as this exact bundle is already installed.
+
+During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT (using the Maven convention). If a bundle with a snapshot version is changed, it gets updated by the OSGI installer.
-<a name="OSGiInstaller-ConfigurationHandling"></a>
## Configuration Handling
-In general the OSGi installer installs the configuration with the highes
-priority. For example in combination with the JCR installer provider, a
-configuration from _/apps_ is preferred over a configuration for the same
-service from _/libs_.
+In general the OSGi installer installs the configuration with the highes priority. For example in combination with the JCR installer provider, a configuration from */apps* is preferred over a configuration for the same service from */libs*.
Added: sling/site/trunk/content/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext?rev=1341347&view=auto
==============================================================================
--- sling/site/trunk/content/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext (added)
+++ sling/site/trunk/content/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext Tue May 22 08:25:18 2012
@@ -0,0 +1,88 @@
+Title: Output Rewriting Pipelines (org.apache.sling.rewriter)
+
+# Apache Sling Rewriter
+
+The Apache Sling Rewriter is a module for rewriting the output generated by a usual Sling rendering process. Some possible use cases include rewriting or checking all links in an html page, manipulating the html page, or using the generated output as the base for further transformation. An example of futher transformation is to use XSLT to transform rendered XML to some output format like HTML or XSL:FO for generating PDF.
+
+For supporting these use cases, the rewriter uses the concept for a processor. The processor is a component that is injected through a servlet filter into the response. By implementing the *Processor* interface one is able to rewrite the whole response in one go. A more convenient way of processing the output is by using a so called pipeline; the Apache Sling rewriter basically uses the same concept as the famous Apache Cocoon: an XML based pipeline for further post processing of the output. The pipeline is based on SAX events.
+
+## SAX Pipelines
+The rewriter allows to configure a pipeline for post processing of the generated response. Depending on how the pipeline is assembled the rewriting process might buffer the whole output in order to do proper post processing - for example this is required if an HTML response is "transformed" to XHTML or if XSLT is used to process the response.
+
+As the pipeline is based on SAX events, there needs to be a component that generates these events and sends them through the pipeline. By default the Sling rendering scripts write to an output stream, so there is a need to parse this output and generate the SAX events.
+
+The first component in the pipeline generating the initial SAX events is called a generator. The generator gets the output from Sling, generates SAX events (XML), and streams these events into the pipeline. The counterpart of the generator is the serializer which builds the end of the pipeline. The serializer collects all incomming SAX events, transforms them into the required response by writing into output stream of the response.
+
+Between the generator and the serializer so called transformers can be placed in a chain. A transformer receives SAX events from the previous component in the pipeline and sends SAX events to the next component in the pipeline. A transformer can remove events, change events, add events or just pass on the events.
+
+Sling contains a default pipeline which is executed for all html responses: it starts with an html generator, parsing the html output and sending events into the pipeline. A html serializer collects all events and serializes the output.
+
+The pipelines can be configured in the repository as a child node of */apps/APPNAME/config/rewriter* (or */libs/APPNAME/config/rewriter*). (In fact the configured search paths of the resource resolver are observed.) Each node can have the following properties:
+* generatorType - the type of the generator (required)
+* transformerTypes (multi value string) - the types of the transformers (optional)
+* serializerType - the type of the serializer (required)
+* paths (multi value string) - the paths this pipeline should run on (content paths)
+* contentTypes (multi value string) - the content types this pipeline should be used for (optional)
+* extensions (multi value string) - the extensions this pipeline should be used for (optional)
+* resourceTypes (multi value string) - the resource types this pipeline should be used for (optional)
+* order (long) - the configurations are sorted by this order, order must be higher or equal to 0. The configuration with the highest order is tried first.
+* enabled (boolean) - Is this configuration active? (default yes)
+
+As you can see from the configuration there are several possibilities to define when a pipeline should be used for a response, like paths, extensions, content types, or resource types. It is possible to specify several of them at once. In this case all conditions must be met.
+
+If a component needs a configuration, the configuration is stored in a child node which name is *\{componentType\}\-\{name\}*, e.g. to configure the html generator (named *html\-generator*), the node should have the name *generator-html-generator*. In the case that the pipeline contains the same transformer several times, the configuration child node should have the formant *\{componentType\}-\{index\}* where index is the index of the transformer starting with 1. For example if you have a pipeline with the following transformers, xslt, html-cleaner, xslt, link-checker, then the configuration nodes should be named *transformer-1* (for the first xslt), *transformer-html-cleaner*, *transformer-3* (for the second xslt), and *transformer-link-checker*.
+
+
+### Default Pipeline
+
+The default pipeline is configured for the *text/html* mime type and the *html* extensions and consists of the *html-generator* as the generator, and the *html-serializer* for generating the final response.
+As the html generated by Sling is not required to be valid XHTML, the html parser is using an HTML parser to create valid SAX events. In order to perform this, the generator needs to buffer the whole response first.
+
+## Implementing Pipeline Components
+
+Each pipeline component type has a corresponding Java interface (Generator, Transformer, and Serializer) together with a factory interface (GeneratorFactory, TransformerFactory, and SerializerFactory). When implementing such a component, both interfaces need to be implemented. The factory has only one method which creates a new instance of that type for the current request. The factory has to be registered as a service. For example if you're using the Maven SCR plugin, it looks like this:
+
+
+ @scr.component metatype="no"
+ @scr.service interface="TransformerFactory"
+ @scr.property value="pipeline.type" value="validator"
+
+
+The factory needs to implement the according interface and should be registered as a service for this factory interface (this is a plain service and not a factory service in the OSGi sense). Each factory gets a unique name through the *pipeline.type* property. The pipeline configuration in the repository just references this unique name (like validator).
+
+## Extending the Pipeline
+With the possibilities from above, it is possible to define new pipelines and add custom components to the pipeline. However, in some cases it is required to just add a custom transformer to the existing pipeline. Therefore the rewriting can be configured with pre and post transformers that are simply added to each configured pipeline. This allows a more flexible way of customizing the pipeline without changing/adding a configuration in the repository.
+
+The approach here is nearly the same. A transformer factory needs to be implemented, but instead of giving this factory a unique name, this factory is marked as a global factory:
+
+ @scr.component metatype="no"
+ @scr.service interface="TransformerFactory"
+ @scr.property name="pipeline.mode" value="global"
+ @scr.property name="service.ranking" value="RANKING" type="Integer"
+
+*RANKING* is an integer value (don't forget the type attribute otherwise the ranking is interpreted as zero!) specifying where to add the transformer in the pipeline. If the value is less than zero the transformer is added at the beginning of the pipeline right after the generator. If the ranking is equal or higher as zero, the transformer is added at the end of the pipeline before the serializer.
+
+The *TransformerFactory* interface has just one method which returns a new transformer instance. If you plan to use other services in your transformer you might declare the references on the factory and pass in the instances into the newly created transformer.
+
+
+## Implementing a Processor
+A processor must conform to the Java interface *org.apache.sling.rewriter.Processor*. It gets initializd (method *init*) with the *ProcessingContext*. This context contains all necessary information for the current request (especially the output writer to write the rewritten content to).
+The *getWriter* method should return a writer where the output is written to. When the output is written or an error occured *finished* is called.
+
+Like the pipeline components a processor is generated by a factory which has to be registered as a service factory, like this:
+
+ @scr.component metatype="no"
+ @scr.service interface="ProcessorFactory"
+ @scr.property value="pipeline.type" value="uniqueName"
+
+
+## Configuring a Processor
+The processors can be configured in the repository as a child node of */apps/APPNAME/config/rewriter* (or libs or any configured search path). Each node can have the following properties:
+* processorType - the type of the processor (required) - this is the part from the scr factory information after the slash (in the example above this is *uniqueName*)
+* paths (multi value string) - the paths this processor should run on (content paths)
+* contentTypes (multi value string) - the content types this processor should be used for (optional)
+* extensions (multi value string) - the extensions this pipeline should be used for (optional)
+* resourceTypes (multi value string) - the resource types this pipeline should be used for (optional)
+* order (long) - the configurations are sorted by this order, order must be higher or equal to 0. The configuration with the highest order is tried first.
+* enabled (boolean) - Is this configuration active? (default yes)
+
Modified: sling/site/trunk/content/plugins.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/plugins.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/plugins.mdtext (original)
+++ sling/site/trunk/content/plugins.mdtext Tue May 22 08:25:18 2012
@@ -1,4 +1,5 @@
Title: Plugins
+
These pages present the various Maven Plugins of Sling:
-{children:excerpt=true}
+{children:excerpt=true}
\ No newline at end of file
Modified: sling/site/trunk/content/project-information.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/project-information.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/project-information.mdtext (original)
+++ sling/site/trunk/content/project-information.mdtext Tue May 22 08:25:18 2012
@@ -1,69 +1,41 @@
Title: Project Information
-<a name="ProjectInformation-Slingprojectinformation"></a>
+
# Sling project information
-This document provides an overview of the various documents and links that
-are part of this project's general information:
+This document provides an overview of the various documents and links that are part of this project's general information:
-* [Community Roles and Processes](apache-sling-community-roles-and-processes.html)
-* [Project Team](project-team.html)
-* [Mailing Lists](#lists.html)
-* [Issue Tracking](#issues.html)
-* [Source Repository](#source.html)
-* [Continuous Integration](#ci.html)
-* [Project License](project-license.html)
+* [Community Roles and Processes]({{ refs.apache-sling-community-roles-and-processes.path }})
+* [Project Team]({{ refs.project-team.path }})
+* [Mailing Lists]({{ refs.-lists.path }})
+* [Issue Tracking]({{ refs.-issues.path }})
+* [Source Repository]({{ refs.-source.path }})
+* [Continuous Integration]({{ refs.-ci.path }})
+* [Project License]({{ refs.project-license.path }})
{anchor:lists}
-<a name="ProjectInformation-MailingLists"></a>
## Mailing Lists
-These are the mailing lists that have been established for this project.
-For each list, there is a subscribe, unsubscribe, and an archive link.
-<table>
-<tr><th> Name </th><th> Subscribe </th><th> Unsubscribe </th><th> Post </th><th> Archive </th><th> Other Archives </th></tr>
-<tr><td> Sling Users List </td><td> [Subscribe](mailto:users-subscribe@sling.apache.org.html)
- </td><td> [Unsubscribe</td><td>mailto:users-unsubscribe@sling.apache.org]
- </td><td> users at sling.apache.org </td><td> [mail-archives.apache.org</td><td>http://mail-archives.apache.org/mod_mbox/sling-users/]
- </td><td> [www.mail-archive.com</td><td>http://www.mail-archive.com/users@sling.apache.org/]
- [MarkMail</td><td>http://sling.markmail.org]
- [Nabble</td><td>http://n3.nabble.com/Sling-Users-f73968.html]
- </td></tr>
-<tr><td> Sling Developers List </td><td> [Subscribe](mailto:dev-subscribe@sling.apache.org.html)
- </td><td> [Unsubscribe</td><td>mailto:dev-unsubscribe@sling.apache.org]
- </td><td> dev at sling.apache.org </td><td> [mail-archives.apache.org</td><td>http://mail-archives.apache.org/mod_mbox/sling-dev/]
- </td><td> [www.mail-archive.com</td><td>http://www.mail-archive.com/dev@sling.apache.org/]
- [MarkMail</td><td>http://sling.markmail.org]
- [Nabble</td><td>http://n3.nabble.com/Sling-Dev-f73966.html]
- </td></tr>
-<tr><td> Sling Source Control List </td><td> [Subscribe](mailto:commits-subscribe@sling.apache.org.html)
- </td><td> [Unsubscribe</td><td>mailto:commits-unsubscribe@sling.apache.org]
- </td><td> </td><td> [mail-archives.apache.org</td><td>http://mail-archives.apache.org/mod_mbox/incubator-sling-commits/]
- </td><td> [www.mail-archive.com</td><td>http://www.mail-archive.com/commits@sling.apache.org/]
- [MarkMail</td><td>http://sling.markmail.org]
- </td></tr>
-</table>
+These are the mailing lists that have been established for this project. For each list, there is a subscribe, unsubscribe, and an archive link.
+| Name | Subscribe | Unsubscribe | Post | Archive | Other Archives |
+|--|--|--|--|--|--|
+| Sling Users List | [Subscribe]({{ refs.mailto-users-subscribe-sling-apache-org.path }}) | [Unsubscribe|mailto:users-unsubscribe@sling.apache.org] | users at sling.apache.org | [mail-archives.apache.org|http://mail-archives.apache.org/mod_mbox/sling-users/] | [www.mail-archive.com|http://www.mail-archive.com/users@sling.apache.org/] [MarkMail|http://sling.markmail.org] [Nabble|http://n3.nabble.com/Sling-Users-f73968.html] |
+| Sling Developers List | [Subscribe]({{ refs.mailto-dev-subscribe-sling-apache-org.path }}) | [Unsubscribe|mailto:dev-unsubscribe@sling.apache.org] | dev at sling.apache.org | [mail-archives.apache.org|http://mail-archives.apache.org/mod_mbox/sling-dev/] | [www.mail-archive.com|http://www.mail-archive.com/dev@sling.apache.org/] [MarkMail|http://sling.markmail.org] [Nabble|http://n3.nabble.com/Sling-Dev-f73966.html] |
+| Sling Source Control List | [Subscribe]({{ refs.mailto-commits-subscribe-sling-apache-org.path }}) | [Unsubscribe|mailto:commits-unsubscribe@sling.apache.org] | | [mail-archives.apache.org|http://mail-archives.apache.org/mod_mbox/incubator-sling-commits/] | [www.mail-archive.com|http://www.mail-archive.com/commits@sling.apache.org/] [MarkMail|http://sling.markmail.org] |
{anchor:issues}
-<a name="ProjectInformation-IssueTracking"></a>
## Issue Tracking
-This project uses JIRA a J2EE-based, issue tracking and project management
-application. Issues, bugs, and feature requests should be submitted to the
-following issue tracking system for this project.
+This project uses JIRA a J2EE-based, issue tracking and project management application. Issues, bugs, and feature requests should be submitted to the following issue tracking system for this project.
-The issue tracker can be found at [http://issues.apache.org/jira/browse/SLING](http://issues.apache.org/jira/browse/SLING)
+The issue tracker can be found at [http://issues.apache.org/jira/browse/SLING]({{ refs.http://issues.apache.org/jira/browse/SLING.path }})
{anchor:source}
-<a name="ProjectInformation-SourceRepository"></a>
## Source Repository
-This project uses Subversion to manage its source code. Instructions on
-Subversion use can be found at [http://svnbook.red-bean.com/](http://svnbook.red-bean.com/)
-.
+This project uses Subversion to manage its source code. Instructions on Subversion use can be found at [http://svnbook.red-bean.com/]({{ refs.http://svnbook.red-bean.com/.path }}).
-<a name="ProjectInformation-WebAccess"></a>
### Web Access
The following is a link to the online source repository.
@@ -72,7 +44,6 @@ The following is a link to the online so
http://svn.apache.org/viewvc/sling/trunk
-<a name="ProjectInformation-Anonymousaccess"></a>
### Anonymous access
The source can be checked out anonymously from SVN with this command:
@@ -81,47 +52,33 @@ The source can be checked out anonymousl
$ svn checkout http://svn.apache.org/repos/asf/sling/trunk sling
-<a name="ProjectInformation-Developeraccess"></a>
### Developer access
-Everyone can access the Subversion repository via HTTPS, but Committers
-must checkout the Subversion repository via HTTPS.
+Everyone can access the Subversion repository via HTTPS, but Committers must checkout the Subversion repository via HTTPS.
$ svn checkout https://svn.apache.org/repos/asf/sling/trunk sling
-To commit changes to the repository, execute the following command to
-commit your changes (svn will prompt you for your password)
+To commit changes to the repository, execute the following command to commit your changes (svn will prompt you for your password)
$ svn commit --username your-username -m "A message"
-<a name="ProjectInformation-Accessfrombehindafirewall"></a>
### Access from behind a firewall
-For those users who are stuck behind a corporate firewall which is blocking
-http access to the Subversion repository, you can try to access it via the
-developer connection:
+For those users who are stuck behind a corporate firewall which is blocking http access to the Subversion repository, you can try to access it via the developer connection:
$ svn checkout https://svn.apache.org/repos/asf/sling/trunk sling
-<a name="ProjectInformation-Accessthroughaproxy"></a>
### Access through a proxy
-The Subversion client can go through a proxy, if you configure it to do so.
-First, edit your "servers" configuration file to indicate which proxy to
-use. The files location depends on your operating system. On Linux or Unix
-it is located in the directory "~/.subversion". On Windows it is in
-"%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden
-directory.)
-
-There are comments in the file explaining what to do. If you don't have
-that file, get the latest Subversion client and run any command; this will
-cause the configuration directory and template files to be created.
+The Subversion client can go through a proxy, if you configure it to do so. First, edit your "servers" configuration file to indicate which proxy to use. The files location depends on your operating system. On Linux or Unix it is located in the directory "~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden directory.)
+
+There are comments in the file explaining what to do. If you don't have that file, get the latest Subversion client and run any command; this will cause the configuration directory and template files to be created.
Example : Edit the 'servers' file and add something like :
@@ -132,10 +89,7 @@ Example : Edit the 'servers' file and ad
{anchor:ci}
-<a name="ProjectInformation-ContinuousIntegration"></a>
## Continuous Integration
-Sling builds run automatically on the ASF's [Jenkins build server](https://builds.apache.org/view/S-Z/view/Sling/)
-, triggered by SVN changes and daily.
+Sling builds run automatically on the ASF's [Jenkins build server]({{ refs.https://builds.apache.org/view/S-Z/view/Sling/.path }}), triggered by SVN changes and daily.
-See [SLING-920](https://issues.apache.org/jira/browse/SLING-920)
- for Hudson configuration information.
+See [SLING-920]({{ refs.https://issues.apache.org/jira/browse/SLING-920.path }}) for Hudson configuration information.
Modified: sling/site/trunk/content/project-license.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/project-license.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/project-license.mdtext (original)
+++ sling/site/trunk/content/project-license.mdtext Tue May 22 08:25:18 2012
@@ -1,8 +1,9 @@
Title: Project License
- Apache License
- Version 2.0, January 2004
- http://www.apache.org/licenses/
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
@@ -41,26 +42,21 @@ Title: Project License
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
- editorial revisions, annotations, elaborations, or other
-modifications
- represent, as a whole, an original work of authorship. For the
-purposes
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
- separable from, or merely link (or bind by name) to the interfaces
-of,
+ separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
- submitted to Licensor for inclusion in the Work by the copyright
-owner
+ submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
- communication on electronic mailing lists, source code control
-systems,
+ communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
@@ -99,33 +95,33 @@ systems,
meet the following conditions:
(a) You must give any other recipients of the Work or
- Derivative Works a copy of this License; and
+ Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
- stating that You changed the files; and
+ stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
- that You distribute, all copyright, patent, trademark, and
- attribution notices from the Source form of the Work,
- excluding those notices that do not pertain to any part of
- the Derivative Works; and
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
- distribution, then any Derivative Works that You distribute must
- include a readable copy of the attribution notices contained
- within such NOTICE file, excluding those notices that do not
- pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
- as part of the Derivative Works; within the Source form or
- documentation, if provided along with the Derivative Works; or,
- within a display generated by the Derivative Works, if and
- wherever such third-party notices normally appear. The contents
- of the NOTICE file are for informational purposes only and
- do not modify the License. You may add Your own attribution
- notices within Derivative Works that You distribute, alongside
- or as an addendum to the NOTICE text from the Work, provided
- that such additional attribution notices cannot be construed
- as modifying the License.
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
@@ -155,8 +151,7 @@ systems,
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
- risks associated with Your exercise of permissions under this
-License.
+ risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
@@ -186,8 +181,7 @@ License.
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
- boilerplate notice, with the fields enclosed by brackets "[]
-"
+ boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
@@ -195,8 +189,7 @@ License.
same "printed page" as the copyright notice for easier
identification within third-party archives.
- Copyright [yyyy]
- [name of copyright owner]
+ Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
Modified: sling/site/trunk/content/project-team.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/project-team.mdtext?rev=1341347&r1=1341346&r2=1341347&view=diff
==============================================================================
--- sling/site/trunk/content/project-team.mdtext (original)
+++ sling/site/trunk/content/project-team.mdtext Tue May 22 08:25:18 2012
@@ -1,66 +1,49 @@
Title: Project Team
-<a name="ProjectTeam-TheProjectTeam"></a>
+
# The Project Team
-A successful project requires many people to play many roles. Some members
-write code or documentation, while others are valuable as testers,
-submitting patches and suggestions.
-
-The team is comprised of Committers and Contributors. Committers have
-direct access to the source of a project and actively evolve the code-base.
-Contributors improve the project through submission of patches and
-suggestions to the Members. The number of Contributors to the project is
-unbounded. Get involved today. All contributions to the project are greatly
-appreciated.
+A successful project requires many people to play many roles. Some members write code or documentation, while others are valuable as testers, submitting patches and suggestions.
+
+The team is comprised of Committers and Contributors. Committers have direct access to the source of a project and actively evolve the code-base. Contributors improve the project through submission of patches and suggestions to the Members. The number of Contributors to the project is unbounded. Get involved today. All contributions to the project are greatly appreciated.
-<a name="ProjectTeam-CommittersandPMCmembers"></a>
## Committers and PMC members
-The following is a list of developers with commit privileges that have
-directly contributed to the project in one way or another.
+The following is a list of developers with commit privileges that have directly contributed to the project in one way or another.
-<table>
-<tr><th> Id </th><th> Name </th><th> Organization </th><th> Roles </th><th> Time Zone </th></tr>
-<tr><td> apopescu (*) </td><td> Alexandru Popescu </td><td> </td><td> Java Developer </td><td> \+1 </td></tr>
-<tr><td> bdelacretaz (*) </td><td> Bertrand Delacretaz </td><td> Adobe </td><td> Java Developer </td><td> \+1 </td></tr>
-<tr><td> </td><td> Clemens Wyss </td><td> MySign AG </td><td> </td><td> \+1 </td></tr>
-<tr><td> clombart (*) </td><td> Christophe Lombart </td><td> </td><td> Java Developer </td><td> \+1 </td></tr>
-<tr><td> cziegeler (*) </td><td> Carsten Ziegeler </td><td> Adobe </td><td> Chair, Java Developer </td><td> \+1 </td></tr>
-<tr><td> fmeschbe (*) </td><td> Felix Meschberger </td><td> Adobe </td><td> Java Developer </td><td> \+1 </td></tr>
-<tr><td> enorman </td><td> Eric Norman </td><td> </td><td> Java Developer </td><td> </td></tr>
-<tr><td> gianugo (*) </td><td> Gianugo Rabellino </td><td> </td><td> </td><td> \+1 </td></tr>
-<tr><td> justin (*) </td><td> Justin Edelson </td><td> Adobe </td><td> Java Developer </td><td> </td></tr>
-<tr><td> hannonpi (*) </td><td> Padraic Hannon </td><td> Edmunds Inc. </td><td> Java Developer </td><td> </td></tr>
-<tr><td> ieb (*) </td><td> Ian Boston </td><td> University of Cambridge </td><td> Java Developer </td><td> </td></tr>
-<tr><td> juanjo (*) </td><td> Juan José Vázquez Delgado </td><td> </td><td> Java Developer </td><td> </td></tr>
-<tr><td> mykee (*) </td><td> Mike Müller </td><td> MySign AG </td><td> </td><td> \+1 </td></tr>
-<tr><td> pauls (*) </td><td> Karl Pauls </td><td> </td><td> Java Developer </td><td> \+1 </td></tr>
-<tr><td> thecarlhall </td><td> Carl Hall </td><td> Hallway Technologies </td><td> Java Developer </td><td> -5 </td></tr>
-<tr><td> vramdal (*) </td><td> Vidar Ramdal </td><td> </td><td> Java Developer </td><td> \+1 </td></tr>
-</table>
+| Id | Name | Organization | Roles | Time Zone |
+|--|--|--|--|--|
+| apopescu (*) | Alexandru Popescu | | Java Developer | \+1 |
+| bdelacretaz (*) | Bertrand Delacretaz | Adobe | Java Developer | \+1 |
+| | Clemens Wyss | MySign AG | | \+1 |
+| clombart (*) | Christophe Lombart | | Java Developer | \+1 |
+| cziegeler (*) | Carsten Ziegeler | Adobe | Chair, Java Developer | \+1 |
+| fmeschbe (*) | Felix Meschberger | Adobe | Java Developer | \+1 |
+| enorman | Eric Norman | | Java Developer | |
+| gianugo (*) | Gianugo Rabellino | | | \+1 |
+| justin (*) | Justin Edelson | Adobe | Java Developer | |
+| hannonpi (*) | Padraic Hannon | Edmunds Inc. | Java Developer | |
+| ieb (*) | Ian Boston | University of Cambridge | Java Developer | |
+| juanjo (*) | Juan José Vázquez Delgado | | Java Developer | |
+| mykee (*) | Mike Müller | MySign AG | | \+1 |
+| pauls (*) | Karl Pauls | | Java Developer | \+1 |
+| thecarlhall | Carl Hall | Hallway Technologies | Java Developer | -5 |
+| vramdal (*) | Vidar Ramdal | | Java Developer | \+1 |
-Committers marked with an asterisk (*) are also members of the Sling Project Management Commitee ([PMC](http://www.apache.org/dev/pmc.html)
-) as defined in [Apache Sling Community Roles and Processes]
+Committers marked with an asterisk (*) are also members of the Sling Project Management Commitee ([PMC]({{ refs.http://www.apache.org/dev/pmc.html.path }})) as defined in [Apache Sling Community Roles and Processes]
-<a name="ProjectTeam-EmeritusCommittersandPMCmembers"></a>
## Emeritus Committers and PMC members
-The following list of former committers and/or PMC members have chosen to
-go emeritus. We are still thankful for their help and guidance during
-earlier phases of the Sling project.
+The following list of former committers and/or PMC members have chosen to go emeritus. We are still thankful for their help and guidance during earlier phases of the Sling project.
-<table>
-<tr><th> Id </th><th> Name </th><th> Organization </th><th> Roles </th><th> Time Zone </th></tr>
-<tr><td> farra </td><td> *J Aaron Farr* </td><td> </td><td> Mentor </td><td> </td></tr>
-<tr><td> jukka </td><td> *Jukka Zitting* </td><td> Day Software </td><td> Champion, Mentor </td><td> +1 </td></tr>
-</table>
+| Id | Name | Organization | Roles | Time Zone |
+|--|--|--|--|--|
+| farra | *J Aaron Farr* | | Mentor | |
+| jukka | *Jukka Zitting* | Day Software | Champion, Mentor | +1 |
-Committers with their names printed in bold face have also been members of
-the PMC (or PPMC during Sling incubation) as defined in [Apache Sling Community Roles and Processes](apache-sling-community-roles-and-processes.html)
+Committers with their names printed in bold face have also been members of the PMC (or PPMC during Sling incubation) as defined in [Apache Sling Community Roles and Processes]({{ refs.apache-sling-community-roles-and-processes.path }})
-<a name="ProjectTeam-Contributors"></a>
## Contributors
-There are no contributors listed for this project.
+There are no contributors listed for this project.
\ No newline at end of file