Author: buildbot
Date: Mon Jan 21 15:41:26 2013
New Revision: 847467

Log:
Staging update by buildbot for sling

Modified:
    websites/staging/sling/trunk/content/   (props changed)
    
websites/staging/sling/trunk/content/documentation/the-sling-engine/architecture.html

Propchange: websites/staging/sling/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Jan 21 15:41:26 2013
@@ -1 +1 @@
-1436419
+1436426

Modified: 
websites/staging/sling/trunk/content/documentation/the-sling-engine/architecture.html
==============================================================================
--- 
websites/staging/sling/trunk/content/documentation/the-sling-engine/architecture.html
 (original)
+++ 
websites/staging/sling/trunk/content/documentation/the-sling-engine/architecture.html
 Mon Jan 21 15:41:26 2013
@@ -89,19 +89,19 @@
       <p>The following is a short list of high-lights of Sling:</p>
 <ul>
 <li><em><a href="">OSGi</a></em> --- The Sling application is built as a 
series of OSGi bundles and makes heavy use of a number of OSGi core and 
compendium services.</li>
-<li><em><a href="">#Sling API</a></em> --- 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.</li>
-<li><em><a href="">#Request Processing</a></em> --- 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.</li>
-<li><em><a href="">#Resources</a></em> --- The central mantra of Sling is the 
<em>Resource</em>, 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.</li>
-<li><em><a href="">#Servlets and Scripts</a></em> --- Servlets and Scripts are 
handled uniformly in that they are represented as resources themselves and are 
accessible by a resource path.</li>
-<li><em><a href="">#Launchpad</a></em> --- 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.</li>
+<li><em><a href="">Sling API</a></em> --- 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.</li>
+<li><em><a href="">Request Processing</a></em> --- 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.</li>
+<li><em><a href="">Resources</a></em> --- The central mantra of Sling is the 
<em>Resource</em>, 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.</li>
+<li><em><a href="">Servlets and Scripts</a></em> --- Servlets and Scripts are 
handled uniformly in that they are represented as resources themselves and are 
accessible by a resource path.</li>
+<li><em><a href="">Launchpad</a></em> --- 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.</li>
 </ul>
 <p>The following sections elaborate on each of these highlights.</p>
 <h2 id="osgi">OSGi</h2>
-<p><a href="">OSGi</a> 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.</p>
+<p><a href="http://www.osgi.org";>OSGi</a> is a consortium that has developed a 
specification to build modular and extensible applications. This offers <a 
href="http://www.osgi.org/About/WhyOSGi";>various benefits</a>. 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.</p>
 <h3 id="osgi-framework">OSGi Framework</h3>
 <p>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:</p>
 <ul>
-<li><em>Module</em> --- Defines how a module, or a <em>Bundle</em> 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 -- <code>Export-Package</code> -- and what a bundle 
requires to be operative -- <code>Import-Package</code> and 
<code>Require-Bundle</code>.</li>
+<li><em>Module</em> --- Defines how a module, or a <em>Bundle</em> 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 <code>Export-Package</code> and what a bundle requires 
to be operative <code>Import-Package</code> and 
<code>Require-Bundle</code>.</li>
 <li><em>Lifecycle</em> --- The lifecycle layer defines the states a bundle may 
be in and describes the state changes. By providing a class, which implements 
the <code>BundleActivator</code> interface and which is named in the 
<code>Bundle-Activator</code> manifest header, a bundle may hook into the 
lifecycle process when the bundle is started and stopped.</li>
 <li><em>Services</em> --- 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.</li>
 </ul>
@@ -141,7 +141,7 @@
 <p>Optionally, PAX Web's implementation of HttpService can be used when Sling 
is launched as a standalone Java Application. See the <a 
href="/documentation/development/maven-launchpad-plugin.html">Maven Launchpad 
Plugin</a> page for information on how to do this.</p>
 <p>See <a href="/documentation/the-sling-engine/the-sling-launchpad.html">The 
Sling Launchpad</a> for more information.</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; 
text-align: right;">
-        Rev. 1341376 by fmeschbe on Tue, 22 May 2012 09:41:06 +0000
+        Rev. 1436426 by ieb on Mon, 21 Jan 2013 15:41:20 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Sling, Sling, Apache, the Apache feather logo, and the Apache 
Sling project


Reply via email to