incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From i..@apache.org
Subject svn commit: r1436426 - /sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
Date Mon, 21 Jan 2013 15:41:21 GMT
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.
 



Mime
View raw message