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