svn commit: r1436426 - /sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext

[ie...@apache.org]

Author: ieb
Date: Mon Jan 21 15:41:20 2013
New Revision: 1436426

URL: http://svn.apache.org/viewvc?rev=1436426&view=rev
Log:
Fixed some formatting and a link.

Modified:
    sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext

Modified: sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext?rev=1436426&r1=1436425&r2=1436426&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext (original)
+++ sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext Mon Jan 21 15:41:20 2013
@@ -3,23 +3,23 @@ Title: Architecture
 The following is a short list of high-lights of Sling:
 
 * *[OSGi]({{ refs.-osgi.path }})* --- The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi core and compendium services.
-* *[#Sling API]({{ refs.-sling-api.path }})* --- To implement content based Web applications with Sling, an API has been defined, this extends the Servlet API and provides more functionality to work on the content.
-* *[#Request Processing]({{ refs.-request-processing.path }})* --- Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
-* *[#Resources]({{ refs.-resources.path }})* --- The central mantra of Sling is the *Resource*, which represents the resource addressed by any request URL. It is the resource that is first resolved when handling a request. Based on the resource, a first servlet or script is then accessed to actually handle the request.
-* *[#Servlets and Scripts]({{ refs.-servlets-and-scripts.path }})* --- Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
-* *[#Launchpad]({{ refs.-launchpad.path }})* --- Sling uses a very thin launcher to integrate with an existing servlet container, launching Sling as a Web application or providing a main class to represent a standalone Java application.
+* *[Sling API]({{ refs.-sling-api.path }})* --- To implement content based Web applications with Sling, an API has been defined, this extends the Servlet API and provides more functionality to work on the content.
+* *[Request Processing]({{ refs.-request-processing.path }})* --- Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
+* *[Resources]({{ refs.-resources.path }})* --- The central mantra of Sling is the *Resource*, which represents the resource addressed by any request URL. It is the resource that is first resolved when handling a request. Based on the resource, a first servlet or script is then accessed to actually handle the request.
+* *[Servlets and Scripts]({{ refs.-servlets-and-scripts.path }})* --- Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
+* *[Launchpad]({{ refs.-launchpad.path }})* --- Sling uses a very thin launcher to integrate with an existing servlet container, launching Sling as a Web application or providing a main class to represent a standalone Java application.
 
 The following sections elaborate on each of these highlights.
 
 ## OSGi
 
-[OSGi]({{ refs.http://www.osgi.org.path }}) is a consortium that has developed a specification to build modular and extensible applications. This offers [various benefits|http://www.osgi.org/About/WhyOSGi]. We deal mainly with two parts of the specifications: The Core Specification, which defines the OSGi Framework and Core Services, and the Compendium Services Specification, which defines a host of services that extend the functionality of the OSGi Framework.
+[OSGi](http://www.osgi.org) is a consortium that has developed a specification to build modular and extensible applications. This offers [various benefits](http://www.osgi.org/About/WhyOSGi). We deal mainly with two parts of the specifications: The Core Specification, which defines the OSGi Framework and Core Services, and the Compendium Services Specification, which defines a host of services that extend the functionality of the OSGi Framework.
 
 ### OSGi Framework
 
 The OSGi Framework is made up of three layers -- Module, Lifecycle, and Services -- that define how extensible applications are built and deployed. The responsibilities of the layers are:
 
-* *Module* --- Defines how a module, or a *Bundle* in OSGi-speak, is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version and more. In addition there are headers which define what a bundle provides -- `Export-Package` -- and what a bundle requires to be operative -- `Import-Package` and `Require-Bundle`.
+* *Module* --- Defines how a module, or a *Bundle* in OSGi-speak, is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version and more. In addition there are headers which define what a bundle provides `Export-Package` and what a bundle requires to be operative `Import-Package` and `Require-Bundle`.
 * *Lifecycle* --- The lifecycle layer defines the states a bundle may be in and describes the state changes. By providing a class, which implements the `BundleActivator` interface and which is named in the `Bundle-Activator` manifest header, a bundle may hook into the lifecycle process when the bundle is started and stopped.
 * *Services* --- For the application to be able to interact, the OSGi Core Specification defines the service layer. This describes a registry for services, which may be shared.