incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r813969 [10/11] - /websites/staging/sling/trunk/content/
Date Sun, 22 Apr 2012 17:09:58 GMT
Modified: websites/staging/sling/trunk/content/servlets.html
==============================================================================
--- websites/staging/sling/trunk/content/servlets.html (original)
+++ websites/staging/sling/trunk/content/servlets.html Sun Apr 22 17:09:56 2012
@@ -79,180 +79,10 @@
     
     <div class="main">
       <div class="breadcrump" style="font-size: 80%;">
-		(TODO: breadcrumb here)
+<a href="/">Home</a>
       </div>
-      <h1 class="title">Servlets</h1>
-      <div>
-	    <p><a name="Servlets-ServletsandScripts"></a></p>
-<h1 id="servlets-and-scripts">Servlets and Scripts</h1>
-<p>Servlets can be registered as OSGi services. The following service
-reference properties are defined for Servlets defined as OSGi services of
-type <em>javax.servlet.Servlet</em>:</p>
-<table>
-<tr><th> Name </th><th> Description </th></tr>
-<tr><td> *sling.servlet.paths* </td><td> A list of absolute paths under which the
-servlet is accessible as a Resource. The property value must either be a
-single String, an array of Strings or a Vector of Strings. </td></tr>
-<tr><td> *sling.servlet.resourceTypes* </td><td> The resource type(s) supported by the
-servlet. The property value must either be a single String, an array of
-Strings or a Vector of Strings. This property is ignored if the
-*sling.servlet.paths* property is set. </td></tr>
-<tr><td> *sling.servlet.selectors* </td><td> The request URL selectors supported by the
-servlet. The selectors must be configured as they would be specified in the
-URL that is as a list of dot-separated strings such as <em>print.a4</em>.
-The property value must either be a single String, an array of Strings or a
-Vector of Strings. This property is ignored if the *sling.servlet.paths*
-property is set. </td></tr>
-<tr><td> *sling.servlet.extensions* </td><td> The request URL extensions supported by
-the servlet for requests. The property value must either be a single
-String, an array of Strings or a Vector of Strings. This property is
-ignored if the *sling.servlet.paths* property is set. </td></tr>
-<tr><td> *sling.servlet.methods* </td><td> The request methods supported by the servlet.
-The property value must either be a single String, an array of Strings or a
-Vector of Strings. This property is ignored if the *sling.servlet.paths*
-property is set. If this property is missing, the value defaults to GET,
-regardless of which methods are actually implemented/handled by the
-servlet.</td></tr>
-<tr><td> *sling.servlet.prefix* </td><td> The prefix or numeric index to make relative
-paths absolute. If the value of this property is a number (int), it defines
-the index of the search path entries from the resource resolver to be used
-as the prefix. The defined search path is used as a prefix to mount this
-servlet. The number can be -1 which always points to the last search entry.
-If the specified value is higher than than the highest index of the search
-paths, the last entry is used. The index starts with 0. If the value of
-this property is a string and parseable as a number, the value is treated
-as if it would be a number. If the value of this property is a string
-starting with "/", this value is applied as a prefix, regardless of the
-configured search paths! If the value is anything else, it is ignored. If
-this property is not specified, it defaults to the default configuration of
-the sling servlet resolver. </td></tr>
-</table>
+   <!--   <h1 class="title">Servlets</h1> -->
 
-<p>A <em>SlingServletResolver</em> listens for <em>Servlet{</em>}services and - given
-the correct service registration properties - provides the servlets as
-resources in the (virtual) resource tree. Such servlets are provided as
-<em>ServletResource</em> instances which adapt to the <em>javax.servlet.Servlet</em>
-class.</p>
-<p>For a Servlet registered as an OSGi service to be used by the Sling Servlet
-Resolver, the either or both of the <em>sling.servlet.paths</em> or the
-<em>sling.servlet.resourceTypes</em> service reference properties must be set.
-If neither is set, the Servlet service is ignored.</p>
-<p>Each path to be used for registration - either from the
-<em>sling.servlet.paths</em> property or constructed from the other
-<em>sling.servlet.*</em> properties - must be absolute. Any relative path is
-made absolute by prefixing it with a root path. This prefix may be set with
-the <em>sling.servlet.prefix</em> service registration property. If this
-property is not set, the first entry in the <em>ResourceResolver</em> search
-path for the <em>ResourceResolver.getResource(String)</em> method is used as the
-prefix. If this entry cannot be derived, a simpe slash - <em>/</em> - is used
-as the prefix.</p>
-<p>If <em>sling.servlet.methods</em> is not specified, the servlet is only
-registered for handling GET requests. Make sure to list all methods you
-want to be handled by this servlet.</p>
-<p><a name="Servlets-Automatedtests"></a></p>
-<h3 id="automated-tests">Automated tests</h3>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/">launchpad/test-services</a>
- module contains test servlets that use various combinations of the above
-properties. </p>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/">launchpad/integration-tests</a>
- module contains a number of tests (like the [ExtensionServletTest|http://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolution/ExtensionServletTest.java]
- for example) that verify the results.</p>
-<p>Such tests run as part of our continuous integration process, to
-demonstrate and verify the behavior of the various servlet registration
-mechanisms, in a way that's guaranteed to be in sync with the actual Sling
-core code. If you have an idea for additional tests, make sure to let us
-know!</p>
-<p><a name="Servlets-Example:RegistrationbyPath"></a></p>
-<h3 id="example-registration-by-path">Example: Registration by Path</h3>
-<div class="codehilite"><pre><span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">paths</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;/libs/sling/sample/html&quot;</span><span class="p">,</span> <span class="s">&quot;/libs/sling/sample/txt&quot;</span> <span class="o">\</span><span class="p">]</span>
-<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">resourceTypes</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;sling/unused&quot;</span> <span class="o">\</span><span class="p">]</span>
-<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">selectors</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;img&quot;</span> <span class="o">\</span><span class="p">]</span>
-<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">extensions</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;html&quot;</span><span class="p">,</span> <span class="s">&quot;txt&quot;</span><span class="p">,</span> <span class="s">&quot;json&quot;</span> <span class="o">\</span><span class="p">]</span>
-</pre></div>
-
-
-<p>A Servlet service registered with these properties is registered under the
-following paths:</p>
-<ul>
-<li><em>/libs/sling/sample/html</em></li>
-<li><em>/libs/sling/sample/txt</em></li>
-</ul>
-<p>The registration properties <em>sling.servlet.resourceTypes</em>,
-<em>sling.servlet.selectors</em> and <em>sling.servlet.extensions</em> <em>are ignored</em>
-because the <em>sling.servlet.paths</em> property is set.</p>
-<p><a name="Servlets-Example:RegistrationbyResourceTypeetc."></a></p>
-<h3 id="example-registration-by-resource-type-etc">Example: Registration by Resource Type etc.</h3>
-<div class="codehilite"><pre><span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">resourceTypes</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;sling/unused&quot;</span> <span class="o">\</span><span class="p">]</span>
-<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">selectors</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;img&quot;</span><span class="p">,</span> <span class="s">&quot;tab&quot;</span> <span class="o">\</span><span class="p">]</span>
-<span class="n">sling</span><span class="o">.</span><span class="n">servlet</span><span class="o">.</span><span class="n">extensions</span> <span class="o">=</span> <span class="o">\</span><span class="p">[</span> <span class="s">&quot;html&quot;</span><span class="p">,</span> <span class="s">&quot;txt&quot;</span><span class="p">,</span> <span class="s">&quot;json&quot;</span> <span class="o">\</span><span class="p">]</span>
-</pre></div>
-
-
-<p>A Servlet service registered with these properties is registered under the
-following paths:</p>
-<ul>
-<li><em>{<em>}prefix</em>/sling/unused/img/html</em></li>
-<li><em>{<em>}prefix</em>/sling/unused/img/txt</em></li>
-<li><em>{<em>}prefix</em>/sling/unused/img/json</em></li>
-<li><em>{<em>}prefix</em>/sling/unused/tab/html</em></li>
-<li><em>{<em>}prefix</em>/sling/unused/tab/txt</em></li>
-<li><em>{<em>}prefix</em>/sling/unused/tab/json</em></li>
-</ul>
-<p>As explained the Servlet is registered for each permutation of the resource
-types, selectors and extension. See above For an explanation of how
-<em>{<em>}prefix{</em></em>} is defined.</p>
-<p><a name="Servlets-ScriptsareServlets"></a></p>
-<h2 id="scripts-are-servlets">Scripts are Servlets</h2>
-<p>The Sling API defines a <em>SlingScript</em> interface which is used to
-represent (executable) scripts inside of Sling. This interface is
-implemented in the <em>scripting/core</em> bundle in the <em>DefaultSlingScript</em>
-class which also implements the <em>javax.servlet.Servlet</em>.</p>
-<p>To further simplify the access to scripts from the Resource tree, the
-<em>scripting/core</em> bundle registers an <em>AdapterFactory</em> to adapt
-Resources to Scripts and Servlets (the <em>SlingScriptAdapterFactory</em>). In
-fact the adapter factory returns instances of the <em>DefaultSlingScript</em>
-class for both Scripts and Servlets.</p>
-<p>From the perspective of the Servlet resolver, scripts and servlets are
-handled exactly the same. In fact, internally, Sling only handles with
-Servlets, whereas scripts are packed inside a Servlet wrapping and
-representing the script.</p>
-<p><a name="Servlets-"></a></p>
-<h2></h2>
-<p><a name="Servlets-DefaultServlet(s)"></a></p>
-<h2 id="default-servlets">Default Servlet(s)</h2>
-<p>As explained in the Resolution Process section above, a default Servlet is
-selected if no servlet (or script) for the current resource type can be
-found. To make the provisioning of a default Servlet as versatile as
-provisioning per resource type Servlets (or scripts), the default Servlet
-is selected with just a special resource type <em>sling/servlet/default</em>.</p>
-<p>The actual Servlet or Script called as the default Servlet is resolved
-exactly the same way as for any resource type. That is, also for the
-default Servlet selection, the request selectors and extension or method
-are considered. Also, the Servlet may be a Servlet registered as an OSGi
-service or it may be a Script stored in the repository or provided by any
-bundle.</p>
-<p>Finally, if not even a registered default Servlet may be resolved for the
-request, because none has been registered, the <em>servlets/resolver</em> bundle
-provides a fall back the <em>DefaultServlet</em> with the following
-functionality:</p>
-<ul>
-<li>If an <em>NonExistingResource</em> was created for the request the
-<em>DefaultServlet</em> sends a 404 (Not Found)</li>
-<li>Otherwise the <em>DefaultServlet</em> sends a 500 (Internal Server Error),
-because normally at least a <em>NonExistingResource</em> should be created</li>
-</ul>
-<p><a name="Servlets-OptingServletinterface"></a></p>
-<h2 id="optingservlet-interface">OptingServlet interface</h2>
-<p>If a registered servlet implements the OptingServlet interface, Sling uses
-that servlet's <em>accepts(SlingHttpServletRequest request)</em> method to
-refine the servlet resolution process.</p>
-<p>In this case, the servlet is only selected for processing the current
-request if its <em>accept</em> method returns true.</p>
-<p><a name="Servlets-ErrorHandlerServlet(s)orScripts"></a></p>
-<h2 id="error-handler-servlets-or-scripts">Error Handler Servlet(s) or Scripts</h2>
-<p>Error handling support is now described on the <a href="errorhandling.html">Errorhandling</a>
- page.</p>
-      </div>
     
         <div class="trademarkFooter"> 
 		Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.

Modified: websites/staging/sling/trunk/content/sling-api.html
==============================================================================
--- websites/staging/sling/trunk/content/sling-api.html (original)
+++ websites/staging/sling/trunk/content/sling-api.html Sun Apr 22 17:09:56 2012
@@ -79,471 +79,10 @@
     
     <div class="main">
       <div class="breadcrump" style="font-size: 80%;">
-		(TODO: breadcrumb here)
+<a href="/">Home</a>
       </div>
-      <h1 class="title">Sling API</h1>
-      <div>
-	    <p><a name="SlingAPI-TheSlingAPI"></a></p>
-<h1 id="the-sling-api">The Sling API</h1>
-<p>{note:title=Work In Progress}
-The contents of this page is being created at the moment. It contains
-incomplete and partially wrong information as the text is adapted from the
-contents of the <a href="component-api.html">Component API</a>
- documentation page.
-{note}</p>
-<p><a name="SlingAPI-Introduction"></a></p>
-<h2 id="introduction">Introduction</h2>
-<p>The <em>Sling API</em> defines a presentation framework to build Web Applications.
-As such the Sling API builds upon the Servlet API but extends the latter
-with new functionality:</p>
-<ul>
-<li>A web page may be built from many different pieces. This aggregation of
-different pieces is comparable to the functionality provided by the Portlet
-API. In contrast to the latter, though, the pieces may themselves be
-aggregates of yet more pieces. So a single web page response may consist of
-a tree of pieces.</li>
-<li>Just like the Servlet API and the Portlet API the Sling API mainly
-defines a Java based framework. Yet the Sling API comes with the intention
-of supporting scripting built.</li>
-<li>In contrast to the Servlet API and the Portlet API, the Sling API is
-resource centric. That is, the request URL does not address a servlet or a
-portlet but a resource represented by an instance of the
-<em>org.apache.sling.api.resource.Resource</em> interface. From this resource
-the implementation of the Sling API will derive a <em>javax.servlet.Servlet</em>
-or <em>org.apache.sling.api.scripting.SlingScript</em> instance, which is used
-to handle the request.</li>
-</ul>
-<p>An implementation of the presentation framework defined by the Sling API is
-called a <em>Sling Framework</em>. The Apache Sling project actually contains two
-implementations of this API: <em>microsling</em> and <em>Sling</em>. microsling (note the
-lowercase <em>m</em>) implements the same request processing mechanisms as <em>Sling</em>
-but is very hardcoded. It serves well as a rapid development environment as
-it is quickly set up, easy to handle and shows results very easily. Sling
-on the other hand is based on an OSGi framework and very flexible, allowing
-the extension of the system in various ways.</p>
-<p><a name="SlingAPI-GoingResourceCentric"></a></p>
-<h2 id="going-resource-centric">Going Resource Centric</h2>
-<p>Traditional web applications are built around the notion of a traditional
-application which is converted into an application which may be used using
-a Web Browser. Web applications consist of a series of servlets and JSP
-scripts, which are called based on configuration in the web application
-deployment descriptor. Such applications are generally based on some
-internal database or some static filesystem content.</p>
-<p>The Sling API on the other hand looks more like a traditional web server
-from the outside, which delivers more or less static content. Thus, while
-the traditional web application uses the request URL to select a piece of
-code to execute, the Sling API uses the URL to select a resource to be
-delivered.</p>
-<p><a name="SlingAPI-ComparsiontotheServletAPI"></a></p>
-<h3 id="comparsion-to-the-servlet-api">Comparsion to the Servlet API</h3>
-<p>The Sling API builds upon the Servlet API. Generally a Sling Framework will
-run inside a Servlet Container and be manifested towards the Servlet
-Container as a single Servlet, which dispatches requests to the Servlets
-and Scripts depending on the request URLs.</p>
-<p>Response rendering may itself be a multi-step operation. Depending on the
-Servlets and Scripts, the rendering may include dispatching for child (or
-even foreign) Resources.</p>
-<p><a name="SlingAPI-ComparisiontothePortletAPI"></a></p>
-<h3 id="comparision-to-the-portlet-api">Comparision to the Portlet API</h3>
-<p>Unlike the Portlet API, which defines one single level of portlet hierarchy
-- portlets are just pieces residing besides each other - the Sling API
-allows for hierarchic structuring of Resources and hence Servlet and Script
-renderings. To support this structuring, the Sling Framework does not
-control the rendering process of all elements on the page like the Portlet
-Container does for the portlets. Instead only the Resource addressed by the
-request URL is processed and it is left to the Servlet or Script rendering
-that Resource to dispatch other Resource/Servlet/Script tupels to add more
-data to the response.</p>
-<p><a name="SlingAPI-ToIteratororToEnumeration"></a></p>
-<h3 id="to-iterator-or-to-enumeration">To Iterator or To Enumeration</h3>
-<p>With the advent of the Java Collection framework in Java 2, the
-<em>Enumeration</em> has been superceded by the <em>Iterator</em>. So the natural
-choice for the Sling API for methods to return enumeratable collection of
-objects would have be to declare the use of <em>Iterator</em> instances. But
-because the Servlet API defines to use <em>Enumeration</em> instances, the Sling
-API will also declare the use of <em>Enumeration</em> instances for consistency
-with the Servlet API extended by the Sling API.</p>
-<p><a name="SlingAPI-RequestProcessing"></a></p>
-<h2 id="request-processing">Request Processing</h2>
-<p>Unlike traditional Servlet API request processing, a Sling API request is
-processed by the Sling Framework in three basic steps:</p>
-<ol>
-<li><em>Resource Resolution</em> - The Sling Framework derives a Resource instance
-from the client request URL. The details of how to resolve the Resource.
-One possible solution would be to map the request URL to a <a href="http://www.jcp.org/en/jsr/detail?id=170">Java Content Repository</a>
- Node and return a Resource representing that Node.</li>
-<li><em>Servlet and Script Resolution</em> - From the Resource created in the first
-step, the Servlet or Script is resolved based on the type of the Resource.
-The resource type is a simple string, whose semantics is defined by the
-Sling Framework. One possible definition could be for the resource type to
-be the primary node type of the Node underlying the Resource.</li>
-<li><em>Input Processing and Response Generation</em> - After getting the Resource
-and the Servlet or Script, the <em>service()</em> method is called or the script
-is evaluated to process any user supplied input and send the response to
-the client. To structure the rendered response page, this method is
-responsible to include other resources. See <em>Dispatching Requests</em> below
-for details. See <em>Error Handling</em> below for a discussion on how exceptions
-and HTTP stati are handled.</li>
-</ol>
-<p><a name="SlingAPI-URLdecomposition"></a></p>
-<h3 id="url-decomposition">URL decomposition</h3>
-<p>During the <em>Resource Resolution</em> step, the client request URL is decomposed
-into the following parts:</p>
-<ol>
-<li><em>Resource Path</em> -  The longest substring of the request URL resolving to
-a Resource such that the resource path is either the complete request URL
-or the next character in the request URL after the resource path is either
-a dot (<em>.</em>) or a slash (<em>/</em>).</li>
-<li><em>Selectors</em> -  If the first character in the request URL after the
-resource path is a dot, the string after the dot upto but not including the
-last dot before the next slash character or the end of the request URL. If
-the resource path spans the complete request URL or if a slash follows the
-resource path in the request URL, no seletors exist. If only one dot
-follows the resource path before the end of the request URL or the next
-slash, no selectors exist.</li>
-<li><em>Extension</em> -  The string after the last dot after the resource path in
-the request URL but before the end of the request URL or the next slash
-after the resource path in the request URL. If a slash follows the resource
-path in the request URL, the extension is empty.</li>
-<li><em>Suffix Path</em> -  If the request URL contains a slash character after the
-resource path and optional selectors and extension, the path starting with
-the slash upto the end of the request URL is the suffix path. Otherwise,
-the suffix path is empty.</li>
-</ol>
-<p><em>Examples</em>: Assume there is a Resource at <em>/a/b</em>, which has no children.</p>
-<table>
-<tr><th> URI </th><th> Resource Path </th><th> Selectors </th><th> Extension </th><th> Suffix </th></tr>
-<tr><td> /a/b               </td><td> /a/b </td><td> null  </td><td> null </td><td> null       </td></tr>
-<tr><td> /a/b.html          </td><td> /a/b </td><td> null  </td><td> html </td><td> null       </td></tr>
-<tr><td> /a/b.s1.html           </td><td> /a/b </td><td> s1    </td><td> html </td><td> null       </td></tr>
-<tr><td> /a/b.s1.s2.html        </td><td> /a/b </td><td> s1.s2 </td><td> html </td><td> null       </td></tr>
-<tr><td> /a/b/c/d           </td><td> /a/b </td><td> null  </td><td> null </td><td> /c/d       </td></tr>
-<tr><td> /a/b.html/c/d      </td><td> /a/b </td><td> null  </td><td> html </td><td> /c/d       </td></tr>
-<tr><td> /a/b.s1.html/c/d       </td><td> /a/b </td><td> s1    </td><td> html </td><td> /c/d       </td></tr>
-<tr><td> /a/b.s1.s2.html/c/d        </td><td> /a/b </td><td> s1.s2 </td><td> html </td><td> /c/d       </td></tr>
-<tr><td> /a/b/c/d.s.txt     </td><td> /a/b </td><td> null  </td><td> null </td><td> /c/d.s.txt </td></tr>
-<tr><td> /a/b.html/c/d.s.txt        </td><td> /a/b </td><td> null  </td><td> html </td><td> /c/d.s.txt </td></tr>
-<tr><td> /a/b.s1.html/c/d.s.txt    </td><td> /a/b </td><td> s1    </td><td> html </td><td> /c/d.s.txt </td></tr>
-<tr><td> /a/b.s1.s2.html/c/d.s.txt </td><td> /a/b </td><td> s1.s2 </td><td> html </td><td> /c/d.s.txt </td></tr>
-</table>
+   <!--   <h1 class="title">Sling API</h1> -->
 
-<p>{info:title=Automated tests and examples}
-The <a href="http://svn.apache.org/repos/asf/sling/trunk/bundles/engine/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java">SlingRequestPathInfoTest</a>
- demonstrates and tests this decomposition. Feel free to suggest additional
-tests that help clarify how this works!
-{info}</p>
-<p><a name="SlingAPI-TheSlingHttpServletRequest"></a></p>
-<h2 id="the-slinghttpservletrequest">The SlingHttpServletRequest</h2>
-<p>The <em>org.apache.sling.api.SlingHttpServletRequest</em> interface defines the
-basic data available from the client request to both action processing and
-response rendering. The <em>SlingHttpServletRequest</em> extends the
-<em>javax.servlet.http.HTTPServletRequest</em>.</p>
-<p>This section describes the data available from the
-<em>SlingHttpServletRequest</em>. For a complete and normative description of
-the methods, refer to the Sling API JavaDoc. The following information is
-represented for reference. In the case of differences between the following
-descriptions and the Sling API JavaDoc, the latter takes precedence.</p>
-<ol>
-<li><em>Resource access</em> - Resources may be accessed from the
-<em>SlingHttpServletRequest</em> object through the following methods:
-<em>getResource()</em>, <em>getResourceResolver()</em>.</li>
-<li><em>Request URL information</em> - In addition to the standard
-<em>HttpServletRequest</em> information the <em>SlingHttpServletRequest</em> provides
-access to the selectors, extension and suffix through the
-<em>getRequestPathInfo()</em> method. Note that the Resource path is not
-directly available form the <em>SlingHttpServletRequest</em> object. Instead it
-is available through the <em>Resource.getPath()</em> method of the Resource
-object retrieved through <em>SlingHttpServletRequest.getResource()</em>.</li>
-<li><em>Request Parameters</em> - To support user input submitted as
-<em>multipart/form-data</em> encoded POST parameters, the Sling API intrduces
-the <em>RequestParameter</em> interface allowing file uploads. Request
-parameters represented as <em>RequestParameter</em> objects are returned by the
-following methods: <em>getRequestParameter(String name)</em>,
-<em>getRequestParameterMap()</em>, <em>getRequestParameters(String name)</em>.</li>
-<li><em>Request Dispatching</em> - In addition to standard Serlvet API request
-dispatching, the Sling API supports dispatching requests to render
-different Resources using <em>RequestDispatcher</em> objects returned by the
-methods: <em>getRequestDispatcher(Resource resource)</em> and
-{{getRequestDispatcher(Resource resource, RequestDispatcherOptions
-options)}}.</li>
-<li><em>Miscellaneous</em> - Finally the ComponentRequest interface provides the
-following methods: <em>getCookie(String name)</em>,
-<em>getRequestProgressTracker()</em>, <em>getResponseContentType()</em>,
-<em>getResponseContentTypes()</em>, <em>getResourceBundle(Locale locale)</em>,
-<em>getServiceLocator()</em>.</li>
-</ol>
-<p>The <em>SlingHttpServletRequest</em> objects are only valid during the time of
-request processing. Servlets and Scripts must not keep references for later
-use. As such, the <em>SlingHttpServletRequest</em> interface and its extensions
-are defined to not be thread safe.</p>
-<p><em>A note on HTTP Sessions</em>: The <em>SlingHttpServletRequest</em> extends the
-<em>HttpSerlvetRequest</em> and thus supports standard HTTP sessions. Be aware,
-though that Sessions are server side sessions and hence violate the
-sessionless principle of REST and therefore should be used with care. It is
-almost always possible to not use sessions.</p>
-<p><a name="SlingAPI-TheSlingHttpServletResponse"></a></p>
-<h2 id="the-slinghttpservletresponse">The SlingHttpServletResponse</h2>
-<p>The <em>org.apache.sling.api.SlingHttpServletResponse</em> interface extends the
-<em>javax.servet.http.HttpServletResponse</em> interface and is currently empty.
-It merely exists for symmetry with the <em>SlingHttpServletRequest</em>.</p>
-<p><a name="SlingAPI-TheResource"></a></p>
-<h2 id="the-resource">The Resource</h2>
-<p>The <em>org.apache.sling.resource.Resource</em> represents the data addressed by
-the request URL. Resources may also be retrieved through the
-<em>org.apache.sling.api.resource.ResourceResolver</em>. Usually this interface
-is not implemented by clients. In certain use cases we call <em>synthetic
-Resource</em> if may be usefull to define a simple object implementing the
-<em>Resource</em> interface. The Sling Framework does not care about the
-concrete implementation of the <em>Resource</em> interface and rather uses the
-defined methods to access required information. The interface defines the
-following methods:</p>
-<ol>
-<li><em>getResourceType()</em> - Returns the type of the resource. This resource
-type is used to resolve the Servlet or Script used to handle the request
-for the resource.</li>
-<li><em>getPath()</em> - Returns the path derived from the client request URL which
-led to the creation of the Resource instance. See the <a href="#url_decomposition-url-decomposition.html">#URL_decomposition URL decomposition</a>
- section above for more information. It is not required, that the Resource
-path be a part of the original client request URL. The request URL may also
-have been mapped to some internal path.</li>
-<li><em>getResourceMetadata()</em> - Returns meta data information about the
-resource in a <em>ResourceMetadata</em> object.</li>
-<li><em>adaptTo(Class<AdapterType> type)</em> - Returns alternative representations
-of the Resource. The concrete supported classes to which the Resource may
-be adapted depends on the implementation. For example a Resource based on a
-JCR Node may support being adapted to the underlying Node, an
-<em>InputStream</em>, an <em>URL</em> or even to a mapped object through JCR Object
-Content Mapping.</li>
-</ol>
-<hr />
-<p><a name="SlingAPI-TheComponent"></a></p>
-<h2 id="the-component">The Component</h2>
-<p>The <em>org.apache.sling.component.Component</em> interface defines the API
-implemented to actually handle requests. As such the Component interface is
-comparable to the =javax.servlet.Servlet= interface. Like those other
-interfaces, the Component interface provides methods for life cycle
-management: <em>init(ComponentContext context)</em>, <em>destroy()</em>.</p>
-<p><a name="SlingAPI-ProcessingtheRequest"></a></p>
-<h3 id="processing-the-request">Processing the Request</h3>
-<p>The Component Framework calls the {{service(ComponentRequest request,
-ComponentResponse response)}} method of the Component to have the component
-process the request optionally processing user input, rendering the
-response and optionally dispatch to other Content/Component tuples to
-provide more response data.</p>
-<p><a name="SlingAPI-ContentanditsComponent"></a></p>
-<h3 id="content-and-its-component">Content and its Component</h3>
-<p>The Content object and a Component form a pair, in which the Content object
-takes the passive part of providing data to the Component and the Component
-takes the active part of acting upon the Content object. As a consequence,
-there always exists a link between a given implementation of the Content
-interface and a given implementation of the Component interface.</p>
-<p>This link is manifested by the Component identifier available from the
-Content object through the <em>Content.getComponentId()</em> method on the one
-hand. On the other hand, the link is manifested by the
-<em>getContentClassName()</em> and <em>createContentInstance()</em> methods of the
-Component interface.</p>
-<p><a name="SlingAPI-ComponentLifecylce"></a></p>
-<h3 id="component-lifecylce">Component Lifecylce</h3>
-<p>When a Component instance is created and added to the Component framework,
-the <em>init(ComponentContext)</em> method is called to prepare and initialize
-the Component. If this method terminates abnormally by throwing an
-exception, the Component is not used. The Component Framework
-implementation may try at a later time to recreate the Component, intialize
-it and use it. If the Component Framework tries to recreate the Component a
-new instance of the Component must be created to be initialized and used.</p>
-<p>When the Component has successfully been initialized, it may be referred to
-by Content objects. When a client request is to be processed, the Content
-object is resolved and the <em>service</em> method on the Component to which the
-Content object refers is called. The <em>service</em> method may - and generally
-will - be called simultaneously to handle different requests in different
-threads. As such, implementations of these methods must be thread safe.</p>
-<p>When the Component Framework decides to take a Component out of service,
-the <em>destroy()</em> method is called to give the Component a chance to
-cleanup any held resources. The destroy method must only be called by the
-Component Framework when no more request processing is using the Component,
-that is no thread may be in the <em>service</em> method of a Component to be
-destroyed. Irrespective of whether the destroy method terminated normally
-or abnormally, the Component will not be used again.</p>
-<p>The addition and removal of Components is at the discretion of the
-Component Framework. A Component may be loaded at framework start time or
-on demand and my be removed at any time. But only one single Component
-instance with the same Component identifier may be active at the same time
-within a single Component Framework instance.</p>
-<p><a name="SlingAPI-TheComponentExtension"></a></p>
-<h3 id="the-componentextension">The ComponentExtension</h3>
-<p>To enhance the core functionality of Components, each Component may have
-zero, one ore more Component Extensions attached. A Component Extensions is
-a Java object implementing the
-<em>org.apache.sling.component.ComponentExtension</em> interface. This interface
-just defines a <em>getName()</em> method to identify extensions.</p>
-<p>The concrete implementation as well as instantiation and management of
-Component Extensions is left to the Component Framework implementation with
-one restriction though: The extensions must be available to the Component
-at the time the <em>init(ComponentContext)</em> method is called may only be
-dropped after the <em>destroy()</em> method terminates.</p>
-<p>The Component interface defines two methods to access Extensions: The
-<em>getExtensions()</em> method returns a <em>java.util.Enumeration</em> of all
-ComponentExtension objects attached to the component. If no Component
-Extension are attached to the Component, an empty enumeration is returned.
-The <em>getExtension(String name)</em> returns the named Component Extension
-attached to the Component or <em>null</em> if no such Component Extension is
-attached to the Component.</p>
-<p>Component Frameworks are allowed to share Component Extension instances of
-the same name between different Component instances. Regardless of whether
-Component Extensions are shared or not, they must be thread safe, as any
-Component Extension may be used within the <em>service</em> method, which
-themselves may be called concurrently.</p>
-<p><a name="SlingAPI-RequestProcessingFilters"></a></p>
-<h2 id="request-processing-filters">Request Processing Filters</h2>
-<p>Similar to the Servlet API providing filters for filtering requests and/or
-responses the Component API provides the
-<em>org.apache.sling.component.ComponentFilter</em> interface. The filters are
-called by a <em>ComponentFilterChain</em> and either handle the request,
-manipulate the request and/or response object and finally forward the
-request and response optionally wrapped to the
-<em>ComponentFilterChain.doFilter(ComponentRequest, ComponentResponse)</em>
-method.</p>
-<p>Like the <em>Component</em>s  filters have a defined lifecycle manifested by
-<em>init</em> and <em>destroy</em> methods. When the filter enters the system, the
-Component Framework calls the <em>ComponentFilter.init(ComponentContext)</em>
-method. Only when this method completes successfully will the filter be put
-into action and be used during request processing. When the filter leaves
-the system, the Component Framework removes the filter from being used in
-filter chains and calls the <em>ComponentFilter.destroy()</em> method. This
-method is not expected to throw any exceptions. The filter may be removed
-from the Component Framework at the discretion of the Component Framework
-or because the filter is being unregistered from the Component Framework by
-some means outside this specification.</p>
-<p>This specification does not define how <em>ComponentFilter</em> objects are
-registered with the Component Framework nor is it specified how the order
-in which the filters are called is defined. Likewise it is outside this
-specification how the filter instances registered with the Component
-Framework are configured.</p>
-<p><a name="SlingAPI-Sessions"></a></p>
-<h2 id="sessions">Sessions</h2>
-<p>The <em>org.apache.sling.component.ComponentSession</em> interface provides a
-way to identify a user across more than one request and to store transient
-information about that user.</p>
-<p>A component can bind an object attribute into a <em>ComponentSession</em> by
-name. The <em>ComponentSession</em> interface defines two scopes for storing
-objects: <em>APPLICATION_SCOPE</em>, <em>COMPONENT_SCOPE</em>. All objects stored in
-the session using the <em>APPLICATION_SCOPE</em> must be available to all the
-components, servlets and JSPs that belong to the same component application
-and that handle a request identified as being a part of the same session.
-Objects stored in the session using the <em>COMPONENT_SCOPE</em> must be
-available to the component during requests for the same content that the
-objects where stored from. Attributes stored in the <em>COMPONENT_SCOPE</em> are
-not protected from other web components of the component application. They
-are just conveniently namespaced.</p>
-<p>The component session extends the Servlet API <em>HttpSession</em>. Therefore
-all <em>HttpSession</em> listeners do apply to the component session and
-attributes set in the component session are visible in the <em>HttpSession</em>
-and vice versa.</p>
-<p>The attribute accessor methods without the <em>scope</em> parameter always refer
-to <em>COMPONENT_SCOPE</em> attributes. To access <em>APPLICATION_SCOPE</em>
-attributes use the accessors taking an explicit <em>scope</em> parameter.</p>
-<p><em>A final note on Sessions</em>: Sessions are server side sessions and hence
-violate the sessionless principle of REST and therefore should be used with
-care. It is almost always possible to not use sessions.</p>
-<p><a name="SlingAPI-DispatchingRequests"></a></p>
-<h2 id="dispatching-requests">Dispatching Requests</h2>
-<p>To include renderings of child Content objects, a
-<em>org.apache.sling.component.ComponentRequestDispatcher</em> object may be
-retrieved from the ComponentContext with which the Component has been
-initialized or from the ComponentRequest provided to the service method.
-Using this dispatcher the reponse of rendering the Content may be included
-by calling the {{ComponentRequestDispatcher.include(ComponentRequest,
-ComponentResponse)}} method.</p>
-<p>This method is comparable to the
-<em>RequestDispatcher.include(ServletRequest, ServletResponse</em> method of the
-Servlet API but dispatching by the <em>ComponentRequestDispatcher</em> does not
-go through the servlet container and stays within the Component Framework.</p>
-<p>The <em>service</em> method of included Components are called with an instance
-of the <em>ComponentRequest</em> interface whose <em>getContent()</em> returns the
-Content object for the included Content.</p>
-<p>When a Component is included by another component the following request
-attributes are set:</p>
-<table>
-<tr><th> *Request Attributes* </th><th> *Type* </th><th> *Description* </th></tr>
-<tr><td> *org.apache.sling.component.request.content* </td><td> String </td><td> The *Content*
-instance to which the client URL resolved. This attribute is set when
-included Components are being rendered and it is not set for the Component
-directly addressed by the client request. </td></tr>
-<tr><td> *org.apache.sling.component.request.component* </td><td> String </td><td> The
-*Component* instance for the *Content* object to which the client URL
-resolved. This attribute is set when included Components are being rendered
-and it is not set for the Component directly addressed by the client
-request. </td></tr>
-</table>
-
-<p><a name="SlingAPI-ErrorHandling"></a></p>
-<h3 id="error-handling">Error Handling</h3>
-<p>While processing requests, the <em>service</em> methods called may have
-problems. Components have multiple options of reporting issues during
-processing to the client:</p>
-<ul>
-<li>Set the status of the HTTP response calling the
-<em>ComponentResponse.setStatus</em> method</li>
-<li>Send an error page calling the <em>ComponentResponse.sendError</em> method</li>
-<li>Throw an exception</li>
-</ul>
-<p>If such an exception is thrown, the Component Framework must act upon the
-exception in one of the following ways:</p>
-<ul>
-<li>If the request is processed through Servlet API request inclusion, the
-exception must be given back to the servlet container. A
-<em>ComponentException</em> is just forwarded as a <em>ServletException</em>. This is
-a requirement of the Servlet API specification which states for included
-requests:</li>
-</ul>
-<p>{quote}</p>
-<p>{quote}</p>
-<ul>
-<li>Otherwise, the Component Framework may handle the error itself in a
-manner similar to the error handling approach defined the Servlet API
-specification (Section SRV 9.9 Error Handling of the Java Servlet
-Specification 2.4). Specifically the request attributes defined by the
-Servlet API specification must be set for the error handler:</li>
-</ul>
-<table>
-<tr><th> *Request Attributes* </th><th> *Type* </th><th> *Description* </th></tr>
-<tr><td> *javax.servlet.error.status_code* </td><td> *java.lang.Integer* </td><td> The status
-code of the response. In the case of an exception thrown from the
-*service*, the code is defined by the Component Framework. </td></tr>
-<tr><td> *javax.servlet.error.exception_type* </td><td> *java.lang.Class* </td><td> The fully
-qualified name of the exception class thrown. This attribute does not
-exist, if error handling does not result from an exception. This attribute
-is maintained for backwards compatibility according to the Servlet API
-Specification. </td></tr>
-<tr><td> *javax.servlet.error.message* </td><td> *java.lang.String* </td><td> The message of
-the exception thrown. This attribute does not exist, if error handling does
-not result from an exception. This attribute is maintained for backwards
-compatibility according to the Servlet API Specification. </td></tr>
-<tr><td> *javax.servlet.error.exception* </td><td> *java.lang.Throwable* </td><td> The
-exception thrown. This attribute does not exist, if error handling does not
-result from an exception. </td></tr>
-<tr><td> *javax.servlet.error.request_uri* </td><td> *java.lang.String* </td><td> The request
-URL whose processing resulted in the error. </td></tr>
-<tr><td> *javax.servlet.error.servlet_name* </td><td> *java.lang.String* </td><td> The name of
-the servlet which yielded the error. The servlet name will generally not
-have any significance inside the Component Framework. </td></tr>
-<tr><td> *org.apache.sling.component.error.componentId* </td><td> *java.lang.String* </td><td>
-The identifier of the Component whose *service* method has caused the
-error. This attribute does not exist, if the Component Framework itself
-caused the error processing. </td></tr>
-* If the Component Framework decides to not handle the error itself, the
-exception must be forwarded to the servlet container as a
-*ComponentException* wrapping the original exception as its root cause.
-</table>
-
-<p>This specification does not define, how error handlers are configured and
-used if the Component Framework provides error handling support. Likewise
-the Component Framework may or may not implement support to handle calls to
-the <em>ComponentResponse.sendError</em> method. The Component Framework may
-also use its own error handling also for errors resulting from request
-processing failures, for example if authentication is required or if the
-request URL cannot be resolved to a Content object.</p>
-      </div>
     
         <div class="trademarkFooter"> 
 		Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.

Modified: websites/staging/sling/trunk/content/sling-testing-tools.html
==============================================================================
--- websites/staging/sling/trunk/content/sling-testing-tools.html (original)
+++ websites/staging/sling/trunk/content/sling-testing-tools.html Sun Apr 22 17:09:56 2012
@@ -79,183 +79,10 @@
     
     <div class="main">
       <div class="breadcrump" style="font-size: 80%;">
-		(TODO: breadcrumb here)
-      </div>
-      <h1 class="title">Sling Testing Tools</h1>
-      <div>
-	    <p><a name="SlingTestingTools-SlingTestingTools"></a></p>
-<h1 id="sling-testing-tools">Sling Testing Tools</h1>
-<p>Sling provides a number of testing tools to support the following use
-cases:
-<em> Run JUnit tests contributed by OSGi bundles in an OSGi system. This does
-not require Sling and should work in other OSGi  environments.
-</em> Run scriptable tests in a Sling instance, using any supported scripting
-language.
-* Run integration tests via HTTP against a Sling instance that is started
-during the Maven build cycle, or independently.</p>
-<p>This page describes those tools, and points to the bundles that implement
-them.</p>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests">testing/samples/integration-tests</a>
- module demonstrates these tools, and is also meant as a sample project to
-show how to run integration tests for Sling-based applications.</p>
-<p>The main Sling integration tests at <a href="https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests">launchpad/integration-tests</a>
- were created before this testing framework, and do not use it yet (as of
-March 2011). The new testing tools are simpler to use, but the "old" tests
-(all 400 of them as I write this) fulfill their validation role for testing
-Sling itself, there's no real need to modify them to use the new tools.</p>
-<p><a name="SlingTestingTools-Server-sideJUnittestscontributedbybundles"></a></p>
-<h1 id="server-side-junit-tests-contributed-by-bundles">Server-side JUnit tests contributed by bundles</h1>
-<p>The services provided by the <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/junit/core">org.apache.sling.junit.core</a>
- bundle allow bundles to register JUnit tests, which are executed
-server-side by the JUnitServlet registered by default at
-<em>/system/sling/junit</em>. This bundle is not dependent on Sling, it should
-work in other OSGi environments.</p>
-<p>{warning:title=JUnit servlet security}
-Note that the JUnitServlet does not require authentication, so it would
-allow any client to run tests. The servlet can be disabled by configuration
-if needed, but in general the <em>/system</em> path should not be accessible to
-website visitors anyway.
-{warning}</p>
-<p>{note:title=SlingJUnitServlet}
-For tighter integration with Sling, the alternate <em>SlingJUnitServlet</em> is
-registered with the <em>sling/junit/testing</em> resource type and <em>.junit</em>
-selector, if the bundle is running in a Sling system. Using this servlet
-instead of the plain JUnitServlet also allows Sling authentication to be
-used for running the tests, and the standard Sling request processing is
-used, including servlet filters for example.
-{note}</p>
-<p>To try the JUnitServlet interactively, install the <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/samples/sample-tests">org.apache.sling.testing.samples.sampletests</a>
- bundle.</p>
-<p>This bundle contains a number of test classes, which are registered with
-the <em>org.apache.sling.junit.core</em> services by way of the
-<em>Sling-Test-Regexp=.</em>Test<em> bundle header, defined in the bundle's
-</em>pom.xml*. The JUnit core services use this regular expression to select
-which classes of the test bundle should be executed as JUnit tests.</p>
-<p>To list the available tests, open http://localhost:8080/system/sling/junit/
-. The servlet shows available tests, and allows you to execute them via a
-POST request.</p>
-<p>Adding a path allows you to select a specific subset of tests, as in
-http://localhost:8080/system/sling/junit/org.apache.sling.junit.remote.html
-- the example integration tests described below use this to selectively
-execute server-side tests. The JUnitServlet provides various output
-formats, including in particular JSON, see
-http://localhost:8080/system/sling/junit/.json for example.</p>
-<p>To supply tests from your own bundles, simply export the tests classes and
-add the <em>Sling-Test-Regexp</em> header to the bundle so that the Sling JUnit
-core services register them as tests.</p>
-<p><a name="SlingTestingTools-InjectionofOSGiservices"></a></p>
-<h3 id="injection-of-osgi-services">Injection of OSGi services</h3>
-<p>The <em>@TestReference</em> annotation is used to inject OSGi services in tests
-that are executed server side.The <em>BundleContext</em> can also be injected in
-this way, see the <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/samples/sample-tests/src/main/java/org/apache/sling/testing/samples/sampletests/OsgiAwareTest.java">OsgiAwareTest</a>
- for an example.</p>
-<p><a name="SlingTestingTools-Curlexamples"></a></p>
-<h2 id="curl-examples">Curl examples</h2>
-<p>Here's an example executing a few tests using curl:</p>
-<p><DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Running tests with curl</B></DIV><DIV class="codeContent panelContent">
-    $ curl -X POST
-http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.sampletests.JUnit.json
-    [{
-        "INFO_TYPE": "test",
-        "description":
-"testPasses(org.apache.sling.testing.samples.sampletests.JUnit3Test)"
-      },{
-        "INFO_TYPE": "test",
-        "description":
-"testPasses(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
-      },{
-        "INFO_TYPE": "test",
-        "description":
-"testRequiresBefore(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
-      }
-    ]</p>
-<p>And another example with a test that fails:
-<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Failing tests with curl</B></DIV><DIV class="codeContent panelContent">
-    $ curl -X POST
-http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.failingtests.JUnit4FailingTest.json
-    [continuous integration|SLINGxSITE:Project Information]</p>
-<p><a name="SlingTestingTools-Scriptableserver-sidetests"></a></p>
-<h1 id="scriptable-server-side-tests">Scriptable server-side tests</h1>
-<p>If the <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/junit/scriptable">org.apache.sling.junit.scriptable</a>
- bundle is active in a Sling system, (in addition to the
-<em>org.apache.sling.junit.core</em> bundle), scriptable tests can be executed
-by the <em>JUnitServlet</em> according to the following rules:</p>
-<ul>
-<li>A node that has the <em>sling:Test</em> mixin is a scriptable test node.</li>
-<li>For security reasons, scriptable test nodes are only executed as tests if
-they are found under <em>/libs</em> or <em>/apps</em>, or more precisely under a path
-that's part of Sling's <em>ResourceResolver</em> search path.</li>
-<li>To execute a test, the scriptable tests provider makes an HTTP requests
-to the test node's path, with a <em>.test.txt</em> selector and extension, and
-expects the output to contain only the string <em>TEST_PASSED</em>. Empty lines
-and comment lines starting with a hash sign (#) are ignored in the output,
-and other lines are reported as failures.</li>
-</ul>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/serverside/scriptable/ScriptableTestsTest.java">ScriptableTestsTest</a>
- class, from the integration test samples module described below, sets up
-such a test node and its accompanying script, and calls the JUnitServlet to
-execute the test. It can be used as a detailed example of how this works.</p>
-<p><a name="SlingTestingTools-Integrationtestsexample"></a></p>
-<h1 id="integration-tests-example">Integration tests example</h1>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests">testing/samples/integration-tests</a>
- module runs some simple integration tests against a Sling Launchpad
-instance that's setup from scratch before running the tests.</p>
-<p>This module's pom and Java code can be used as examples to setup your own
-integration testing modules for Sling-based apps - or for any other
-runnable jar that provides an http service.</p>
-<p>Besides serving as examples, some of the tests in this module are used to
-validate the testing tools. They run as part of the full Sling <a href="project-information.html">continuous integration</a>
- build, so they're guaranteed to be correct examples if that build is
-successful.</p>
-<p>The sample uses the <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/tools">testing/tools</a>
- to make the test code simpler. See the [OsgiConsoleTest|https://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/http/OsgiConsoleTest.java]
- class for an example of a test that's very readable and requires no test
-setup or boilerplate code.</p>
-<p>The following steps are executed in the <em>integration-test</em> phase of this
-module's Maven  build:
-1. A random port number for the Sling server is selected by the Maven build
-helper plugin, unless explicitely set (see pom.xml for such options).
-1. Additional bundles, defined in the module's pom, are downloaded from the
-Maven repository in the <em>target/sling/additional-bundles</em> folder.
-1. The first test that inherits from the <a href="https://svn.apache.org/repos/asf/sling/trunk/testing/tools/src/main/java/org/apache/sling/testing/tools/sling/SlingTestBase.java">SlingTestBase</a>
- class causes the Sling runnable jar (defined as a dependency in the
-module's pom) to be started. 
-1. # The <em>SlingTestBase</em> class waits for the Sling server to be ready,
-based on URLs and expected responses defined in the pom.
-1. # The <em>SlingTestBase</em> class installs and starts the bundles found in the
-<em>target/sling/additional-bundles</em> folder.
-1. The test can now either test Sling directly via its http interface, or
-use the JUnitServlet to execute server-side tests contributed by bundles or
-scripts, as described above.
-1. The Sling runnable jar is stopped when the test VM exits.
-1. The test results are reported via the usual Maven mechanisms.</p>
-<p>If <em>-DkeepJarRunning</em> is used on the Maven command line, the Sling
-runnable jar does not exit, to allow for running individual tests against
-this instance, for example when debugging the tests or the server code. See
-the pom for details.</p>
-<p><a name="SlingTestingTools-Remotetestexecution"></a></p>
-<h1 id="remote-test-execution">Remote test execution</h1>
-<p>The testing tools support two types of remote test execution.</p>
-<p><a name="SlingTestingTools-SlingRemoteTestRunner"></a></p>
-<h2 id="slingremotetestrunner">SlingRemoteTestRunner</h2>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/testrunner/SlingRemoteTestRunner.java">SlingRemoteTestRunner</a>
- is used to run tests using the <em>JUnitServlet</em> described above. In this
-case, the client-side JUnit test only defines which tests to run and some
-optional assertions. Checking the number of tests executed, for example,
-can be useful to make sure all test bundles have been activated as
-expected, to avoid ignoring missing test bundles.</p>
-<p>See the <a href="https://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/serverside/ServerSideSampleTest.java">ServerSideSampleTest</a>
- class for an example.</p>
-<p><a name="SlingTestingTools-SlingRemoteExecutionRule"></a></p>
-<h2 id="slingremoteexecutionrule">SlingRemoteExecutionRule</h2>
-<p>The <a href="http://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/ide/SlingRemoteExecutionRule.java">SlingRemoteExecutionRule</a>
- is a JUnit Rule that allows tests to be executed remotely in a Sling
-instance from an IDE, assuming the test is available on both sides.</p>
-<p>The <a href="https://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/exported/ExampleRemoteTest.java">ExampleRemoteTest</a>
- class demonstrates this. To run it from your IDE, set the
-<em>sling.remote.test.url</em> in the IDE to the URL of the JUnitServlet, like
-http://localhost:8080/system/sling/junit for example.</p>
+<a href="/">Home</a>
       </div>
+   <!--   <h1 class="title">Sling Testing Tools</h1> -->
+
     
         <div class="trademarkFooter"> 
 		Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.

Modified: websites/staging/sling/trunk/content/sling.html
==============================================================================
--- websites/staging/sling/trunk/content/sling.html (original)
+++ websites/staging/sling/trunk/content/sling.html Sun Apr 22 17:09:56 2012
@@ -79,390 +79,10 @@
     
     <div class="main">
       <div class="breadcrump" style="font-size: 80%;">
-		(TODO: breadcrumb here)
+<a href="/">Home</a>
       </div>
-      <h1 class="title">Sling</h1>
-      <div>
-	    <p><a name="Sling-MavenSlingPlugin"></a></p>
-<h1 id="maven-sling-plugin">Maven Sling Plugin</h1>
-<p>The Maven Sling Plugin provides a number of goals which may be of help
-while developping bundles for Sling. To run the plugin you need at least
-Maven 2.x and JDK 1.5 or higher. Maven Sling Plugin provides the following
-goals:</p>
-<table>
-<tr><td> [sling:deploy](#deploy.html)
- </td><td> Deploy a OSGi-bundle into a running Sling instance. </td></tr>
-<tr><td> [sling:deploy-file](#deploy-file.html)
- </td><td> Deploy a OSGi-bundle into a running Sling instance without requiring a
-project descriptor file. </td></tr>
+   <!--   <h1 class="title">Sling</h1> -->
 
-<tr><td> [sling:install-file](#install-file.html)
- </td><td> Install a OSGi-bundle into a running Sling instance without requiring a
-project descriptor file. </td></tr>
-
-</table>
-
-<p><a name="Sling-Usage"></a></p>
-<h2 id="usage">Usage</h2>
-<p>You should specify the version in your project's plugin configuration:</p>
-<div class="codehilite"><pre><span class="nt">&lt;project&gt;</span>
-  ...
-  <span class="nt">&lt;build&gt;</span>
-    <span class="c">&lt;!-- To define the plugin version in your parent POM --&gt;</span>
-    <span class="nt">&lt;pluginManagement&gt;</span>
-      <span class="nt">&lt;plugins&gt;</span>
-    <span class="nt">&lt;plugin&gt;</span>
-      <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-      <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-      <span class="nt">&lt;version&gt;</span>2.0.5-SNAPSHOT<span class="nt">&lt;/version&gt;</span>
-    <span class="nt">&lt;/plugin&gt;</span>
-    ...
-      <span class="nt">&lt;/plugins&gt;</span>
-    <span class="nt">&lt;/pluginManagement&gt;</span>
-    <span class="c">&lt;!-- To use the plugin goals in your POM or parent POM --&gt;</span>
-    <span class="nt">&lt;plugins&gt;</span>
-      <span class="nt">&lt;plugin&gt;</span>
-    <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-    <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-    <span class="nt">&lt;version&gt;</span>2.0.5-SNAPSHOT<span class="nt">&lt;/version&gt;</span>
-      <span class="nt">&lt;/plugin&gt;</span>
-      ...
-    <span class="nt">&lt;/plugins&gt;</span>
-  <span class="nt">&lt;/build&gt;</span>
-  ...
-<span class="nt">&lt;/project&gt;</span>
-</pre></div>
-
-
-<p>For more information, see <a href="http://maven.apache.org/guides/mini/guide-configuring-plugins.html">"Guide to Configuring Plug-ins"</a></p>
-<p>{anchor:deploy}</p>
-<p><a name="Sling-The*deploy*goal"></a></p>
-<h2 id="the-deploy-goal">The <em>deploy</em> goal</h2>
-<p>The <em>deploy</em> goal uploads a bundle to a Sling OSGi Bundle Repository
-server implemented by the <em>sling-obr</em> bundle, which may be located on a
-remote system. The plugin places an HTTP <em>POST</em> request to the server
-sending the bundle file.&nbsp;</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use">Use</h3>
-<p>To use the <em>deploy</em> goal of the Maven Sling Plugin define the following
-elements in the <em><plugins></em> section of the POM:</p>
-<div class="codehilite"><pre><span class="cp">&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;</span>
-<span class="nt">&lt;project&gt;</span>
-  ....
-  <span class="nt">&lt;build&gt;</span>
-    ....
-    <span class="nt">&lt;plugins&gt;</span>
-      ....
-      <span class="nt">&lt;plugin&gt;</span>
-    <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-    <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-    <span class="nt">&lt;executions&gt;</span>
-      <span class="nt">&lt;execution&gt;</span>
-        <span class="nt">&lt;id&gt;</span>deploy-bundle<span class="nt">&lt;/id&gt;</span>
-        <span class="nt">&lt;goals&gt;</span>
-          <span class="nt">&lt;goal&gt;</span>deploy<span class="nt">&lt;/goal&gt;</span>
-        <span class="nt">&lt;/goals&gt;</span>
-      <span class="nt">&lt;/execution&gt;</span>
-    <span class="nt">&lt;/executions&gt;</span>
-      <span class="nt">&lt;/plugin&gt;</span>
-      ....
-    <span class="nt">&lt;plugins&gt;</span>
-    ....
-  <span class="nt">&lt;build&gt;</span>
-  ....
-<span class="nt">&lt;project&gt;</span>
-</pre></div>
-
-
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration">Configuration</h3>
-<p>The <em>deploy</em> goal may be configured in the <em><configuration></em> element
-using the following properties:
-<table>
-<tr><th> Parameter </th><th> Default Value </th><th> System Property Overwrite </th><th> Description
-</th></tr>
-<tr><td> <em>skip</em> </td><td> <em>false</em> </td><td> <em>sling.deploy.skip</em> </td><td> Whether to skip this step
-even though it has been configured in the project to be executed. The main
-use of this setting is preventing deployment of the bundle to a Sling OSGi
-Bundle Repository server if it is known that there is none or if such an
-upload is not required. </td></tr>
-<tr><td> <em>buildDirectory</em> </td><td> <em>${project.build.directory</em>} </td><td> - </td><td> The path of
-the file to be installed </td></tr>
-<tr><td> <em>jarName</em> </td><td> <em>${project.build.finalName}.jar</em> </td><td> - </td><td> The name of the
-file to be installed </td></tr>
-<tr><td> <em>obr</em> </td><td> - </td><td> <em>obr</em> </td><td> The URL of the running Sling instance to which
-the bundle is installed. Note that this parameter is required and has no
-defualt value. It must always be specified in the configuration section or
-on the command line. </td></tr>
-{anchor:deploy-file}
-</table></p>
-<p><a name="Sling-The*deploy-file*goal"></a></p>
-<h2 id="the-deploy-file-goal">The <em>deploy-file</em> goal</h2>
-<p>The <em>deploy-file</em> goal is equivalent to the <em>deploy</em> goal except, that
-the <em>deploy-file</em> does not require a project descriptor file while the
-<em>deploy</em> goal does. In other words the <em>deploy-file</em> goal may used to
-upload any bundle file available to a Sling OBR server instance.</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use_1">Use</h3>
-<p>The <em>deploy-file</em> goal may only be used from the command line by
-explicitly calling it as in:</p>
-<div class="codehilite"><pre><span class="nv">$</span> <span class="nv">mvn</span> <span class="n">org</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">sling:maven</span><span class="o">-</span><span class="n">sling</span><span class="o">-</span><span class="n">plugin:deploy</span><span class="o">-</span><span class="n">file</span> <span class="o">-</span><span class="n">Dsling</span><span class="o">.</span><span class="n">file</span><span class="o">=</span><span class="sr">&lt;file&gt;</span>
-</pre></div>
-
-
-<p>-Dobr=<url></p>
-<p>Specifying the bundle file to upload with the <em>sling.file</em> property is
-required.</p>
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration_1">Configuration</h3>
-<p>The <em>deploy-file</em> supports similar configuration parameters as the
-<em>deploy</em> goal with the exception of the <em>skip</em> parameter which makes no
-sense. In addition, all parameters must be specified on the command line by
-setting system properties. The <em>bundleFileName</em> parameter specified as
-the <em>sling.file</em> system property as well as the <em>obr</em> URL are required
-by the <em>deploy-file</em> goal.
-<table>
-<tr><th> Parameter </th><th> Default Value </th><th> System Property Overwrite </th><th> Description
-</th></tr>
-<tr><td> <em>bundleFileName</em> </td><td>
-<em>${project.build.directory}/${project.build.finalName}.jar</em> </td><td>
-<em>sling.file</em> </td><td> The path and name of the file to be installed </td></tr>
-<tr><td> <em>obr</em> </td><td> - </td><td> <em>obr</em> </td><td> The URL of the running Sling instance to which
-the bundle is installed. Note that this parameter is required and has no
-defualt value. It must always be specified in the configuration section or
-on the command line. </td></tr>
-Example: To deploy the bundle file <em>someBundle.jar</em> to the OBR running at {{<a href="http://obr.sample.org">http://obr.sample.org</a>
-}} you might use the goal as follows:</p>
-<div class="codehilite"><pre><span class="nv">$</span> <span class="nv">mvn</span> <span class="n">org</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">sling:maven</span><span class="o">-</span><span class="n">sling</span><span class="o">-</span><span class="n">plugin:deploy</span><span class="o">-</span><span class="n">file</span>
-</pre></div>
-
-
-<p>-Dsling.file=someBundle.jar -Dobr=http://obr.sample.org</p>
-<p>{anchor:install}</p>
-<p><a name="Sling-The*install*goal"></a></p>
-<h2 id="the-install-goal">The <em>install</em> goal</h2>
-<p>The <em>install</em> goal uploads a bundle to a running sling instance, which
-may be located on a remote system. The plugin places an HTTP <em>POST</em>
-request to the sling instance sending the bundle file together with flags
-indicating whether to start the bundle and what start level to assign the
-bundle. It's also possible to HTTP <em>PUT</em> instead of <em>POST</em> for WebDAV.</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use_2">Use</h3>
-<p>To use the <em>install</em> goal of the Maven Sling Plugin define the following
-elements in the <em><plugins></em> section of the POM:</p>
-<div class="codehilite"><pre><span class="cp">&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;</span>
-<span class="nt">&lt;project&gt;</span>
-  ....
-  <span class="nt">&lt;build&gt;</span>
-    ....
-    <span class="nt">&lt;plugins&gt;</span>
-      ....
-      <span class="nt">&lt;plugin&gt;</span>
-    <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-    <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-    <span class="nt">&lt;executions&gt;</span>
-      <span class="nt">&lt;execution&gt;</span>
-        <span class="nt">&lt;id&gt;</span>install-bundle<span class="nt">&lt;/id&gt;</span>
-        <span class="nt">&lt;goals&gt;</span>
-          <span class="nt">&lt;goal&gt;</span>install<span class="nt">&lt;/goal&gt;</span>
-        <span class="nt">&lt;/goals&gt;</span>
-      <span class="nt">&lt;/execution&gt;</span>
-    <span class="nt">&lt;/executions&gt;</span>
-      <span class="nt">&lt;/plugin&gt;</span>
-      ....
-    <span class="nt">&lt;plugins&gt;</span>
-    ....
-  <span class="nt">&lt;build&gt;</span>
-  ....
-<span class="nt">&lt;project&gt;</span>
-</pre></div>
-
-
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration_2">Configuration</h3>
-<p>The <em>install</em> goal may be configured in the <em><configuration></em> element
-using the following properties:
-<table>
-<tr><th> Parameter </th><th> Default Value </th><th> System Property Overwrite </th><th> Description
-</th></tr>
-<tr><td> <em>skip</em> </td><td> <em>false</em> </td><td> <em>sling.install.skip</em> </td><td> Whether to skip this step
-even though it has been configured in the project to be executed. The main
-use of this setting is preventing installation of the bundle to a running
-Sling installation if it is known that there is none or if such an upload
-is not required, for example when building the bundle in an automated build
-system such as Confluence. </td></tr>
-<tr><td> <em>bundleFileName</em> </td><td>
-<em>${project.build.directory}/${project.build.finalName}.jar</em> </td><td>
-<em>sling.file</em> </td><td> The path and name of the file to be installed </td></tr>
-<tr><td> <em>bundleStart</em> </td><td> <em>true</em> </td><td> <em>sling.bundle.start</em> </td><td> Whether to start
-the bundle after installing it. If the bundle is just updated, this
-parameter is ignored even if the bundle is currently stopped </td></tr>
-<tr><td> <em>bundleStartLevel</em> </td><td> <em>20</em> </td><td> <em>sling.bundle.startlevel</em> </td><td> The start
-level to set on the installed bundle. If the bundle is already installed
-and therefore is only updated this parameter is ignored. The parameter is
-also ignored if the running Sling instance has no StartLevel service (which
-is unusual actually) </td></tr>
-<tr><td> <em>slingUrl</em> </td><td> <em>http{</em>}<em>://localhost:8080/sling</em> </td><td> <em>sling.url</em> </td><td>
-The URL of the running Sling instance to which the bundle is installed </td></tr>
-<tr><td> <em>user</em> </td><td> <em>admin</em> </td><td> <em>sling.user</em> </td><td> The name of the user to
-authenticate as with the running Sling instance given by the <em>slingUrl</em>
-parameter </td></tr>
-<tr><td> <em>password</em> </td><td> <em>admin</em> </td><td> <em>sling.password</em> </td><td> The password of the user
-to authenticate as with the running Sling instance given by the
-<em>slingUrl</em> parameter </td></tr></p>
-<tr><td> *usePut* </td><td> *false* </td><td> *sling.usePut* </td><td> If a simple HTTP PUT should
-be used instead of the standard POST to the  felix console. In the
-uninstall goal, a HTTP DELETE will be  used. </td></tr>
-
-<tr><td> *refreshPackages* </td><td> *true* </td><td> *sling.refreshPackages* </td><td> Whether to refresh the packages after installing the uploaded bundle. If this property is set to *true*, the {{PackageAdmin.refreshPackages(Bundle\[\](\.html)
-)}} method is called after installing or updating the bundle. </td></tr>
-
-<p>{anchor:install-file}
-</table></p>
-<p><a name="Sling-The*install-file*goal"></a></p>
-<h2 id="the-install-file-goal">The <em>install-file</em> goal</h2>
-<p>The <em>install-file</em> goal is equivalent to the <em>install</em> goal except,
-that the <em>install-file</em> does not require a project descriptor file while
-the <em>install</em> goal does. In other words the <em>install-file</em> goal may
-used to upload any bundle file available to a running Sling instance.</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use_3">Use</h3>
-<p>The <em>install-file</em> goal may only be used from the command line by
-explicitly calling it as in:</p>
-<div class="codehilite"><pre><span class="nv">$</span> <span class="nv">mvn</span> <span class="n">org</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">sling:maven</span><span class="o">-</span><span class="n">sling</span><span class="o">-</span><span class="n">plugin:install</span><span class="o">-</span><span class="n">file</span> <span class="o">-</span><span class="n">Dsling</span><span class="o">.</span><span class="n">file</span><span class="o">=</span><span class="sr">&lt;file&gt;</span>
-</pre></div>
-
-
-<p>Specifying the bundle file to upload with the <em>sling.file</em> property is
-required.</p>
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration_3">Configuration</h3>
-<p>The <em>install-file</em> supports the same configuration parameters as the
-<em>install</em> goal with the exception of the <em>skip</em> parameter which makes
-no sense. In addition, all parameters must be specified on the command line
-by setting system properties. The <em>bundleFileName</em> parameter specified as
-the <em>sling.file</em> system property is required by the <em>install-file</em>
-goal.</p>
-<p>For a description of the parameters see the configuration section of the <a href="#install.html"><em>install</em> goal</a>
- above.</p>
-<p>Example: To upload the bundle file <em>someBundle.jar</em> you might use the
-goal as follows:</p>
-<div class="codehilite"><pre><span class="nv">$</span> <span class="nv">mvn</span> <span class="n">org</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">sling:maven</span><span class="o">-</span><span class="n">sling</span><span class="o">-</span><span class="n">plugin:install</span><span class="o">-</span><span class="n">file</span>
-</pre></div>
-
-
-<p>-Dsling.file=someBundle.jar</p>
-<p>{anchor:uninstall}</p>
-<p><a name="Sling-The*uninstall*goal"></a></p>
-<h2 id="the-uninstall-goal">The <em>uninstall</em> goal</h2>
-<p>The <em>uninstall</em> goal uninstalls a bundle from a running sling instance,
-which may be located on a remote system. The plugin uninstalles a bundle
-via a HTTP <em>POST{</em>}request. It's also possible to use HTTP <em>DELETE</em>
-instead of <em>POST</em> for WebDAV.</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use_4">Use</h3>
-<p>To use the <em>uninstall</em> goal of the Maven Sling Plugin define the
-following elements in the <em><plugins></em> section of the POM:</p>
-<div class="codehilite"><pre><span class="cp">&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;</span>
-<span class="nt">&lt;project&gt;</span>
-  ....
-  <span class="nt">&lt;build&gt;</span>
-    ....
-    <span class="nt">&lt;plugins&gt;</span>
-      ....
-      <span class="nt">&lt;plugin&gt;</span>
-    <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-    <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-    <span class="nt">&lt;executions&gt;</span>
-      <span class="nt">&lt;execution&gt;</span>
-        <span class="nt">&lt;id&gt;</span>uninstall-bundle<span class="nt">&lt;/id&gt;</span>
-        <span class="nt">&lt;goals&gt;</span>
-          <span class="nt">&lt;goal&gt;</span>uninstall<span class="nt">&lt;/goal&gt;</span>
-        <span class="nt">&lt;/goals&gt;</span>
-      <span class="nt">&lt;/execution&gt;</span>
-    <span class="nt">&lt;/executions&gt;</span>
-      <span class="nt">&lt;/plugin&gt;</span>
-      ....
-    <span class="nt">&lt;plugins&gt;</span>
-    ....
-  <span class="nt">&lt;build&gt;</span>
-  ....
-<span class="nt">&lt;project&gt;</span>
-</pre></div>
-
-
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration_4">Configuration</h3>
-<p>The <em>uninstall</em> goal may be configured in the <em><configuration></em> element
-using the following properties:
-<table>
-<tr><th> Parameter </th><th> Default Value </th><th> System Property Overwrite </th><th> Description
-</th></tr>
-<tr><td> <em>bundleFileName</em> </td><td>
-<em>${project.build.directory}/${project.build.finalName}.jar</em> </td><td>
-<em>sling.file</em> </td><td> The path and name of the file to be uninstalled </td></tr>
-<tr><td> <em>slingUrl</em> </td><td> <em>http{</em>}<em>://localhost:8080/sling</em> </td><td> <em>sling.url</em> </td><td>
-The URL of the running Sling instance to which the bundle should be
-uninstalled </td></tr>
-<tr><td> <em>user</em> </td><td> <em>admin</em> </td><td> <em>sling.user</em> </td><td> The name of the user to
-authenticate as with the running Sling instance given by the <em>slingUrl</em>
-parameter </td></tr>
-<tr><td> <em>password</em> </td><td> <em>admin</em> </td><td> <em>sling.password</em> </td><td> The password of the user
-to authenticate as with the running Sling instance given by the
-<em>slingUrl</em> parameter </td></tr>
-<tr><td> <em>usePut</em> </td><td> <em>false</em> </td><td> <em>sling.usePut</em> </td><td> In the uninstall goal, a HTTP
-DELETE will be used. </td></tr>
-{anchor:validate}
-</table></p>
-<p><a name="Sling-The*validate*goal"></a></p>
-<h2 id="the-validate-goal">The <em>validate</em> goal</h2>
-<p>The <em>validate</em> goal checks the JSON code of a bundle.</p>
-<p><a name="Sling-Use"></a></p>
-<h3 id="use_5">Use</h3>
-<p>To use the <em>validate</em> goal of the Maven Sling Plugin define the following
-elements in the <em><plugins></em> section of the POM:</p>
-<div class="codehilite"><pre><span class="cp">&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;</span>
-<span class="nt">&lt;project&gt;</span>
-  ....
-  <span class="nt">&lt;build&gt;</span>
-    ....
-    <span class="nt">&lt;plugins&gt;</span>
-      ....
-      <span class="nt">&lt;plugin&gt;</span>
-    <span class="nt">&lt;groupId&gt;</span>org.apache.sling<span class="nt">&lt;/groupId&gt;</span>
-    <span class="nt">&lt;artifactId&gt;</span>maven-sling-plugin<span class="nt">&lt;/artifactId&gt;</span>
-    <span class="nt">&lt;executions&gt;</span>
-      <span class="nt">&lt;execution&gt;</span>
-        <span class="nt">&lt;id&gt;</span>validate-bundle<span class="nt">&lt;/id&gt;</span>
-        <span class="nt">&lt;goals&gt;</span>
-          <span class="nt">&lt;goal&gt;</span>validate<span class="nt">&lt;/goal&gt;</span>
-        <span class="nt">&lt;/goals&gt;</span>
-      <span class="nt">&lt;/execution&gt;</span>
-    <span class="nt">&lt;/executions&gt;</span>
-      <span class="nt">&lt;/plugin&gt;</span>
-      ....
-    <span class="nt">&lt;plugins&gt;</span>
-    ....
-  <span class="nt">&lt;build&gt;</span>
-  ....
-<span class="nt">&lt;project&gt;</span>
-</pre></div>
-
-
-<p><a name="Sling-Configuration"></a></p>
-<h3 id="configuration_5">Configuration</h3>
-<p>The <em>validate</em> goal may be configured in the <em><configuration></em> element
-using the following properties:
-<table>
-<tr><th> Parameter </th><th> Default Value </th><th> System Property Overwrite </th><th> Description
-</th></tr>
-<tr><td> <em>skip</em> </td><td> <em>false</em> </td><td> <em>sling.validation.skip</em> </td><td> Whether to skip the
-validation </td></tr>
-<tr><td> <em>skipJson</em> </td><td> <em>false</em> </td><td> <em>sling.validation.skipJson</em> </td><td> Whether to
-skip the JSON validation. At the time, there's no difference between
-<em>skip</em> and <em>skipJson</em> because only JSON files will be validated by now.
-</td></tr></p>
-      </div>
     
         <div class="trademarkFooter"> 
 		Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.

Modified: websites/staging/sling/trunk/content/the-sling-engine.html
==============================================================================
--- websites/staging/sling/trunk/content/the-sling-engine.html (original)
+++ websites/staging/sling/trunk/content/the-sling-engine.html Sun Apr 22 17:09:56 2012
@@ -79,43 +79,10 @@
     
     <div class="main">
       <div class="breadcrump" style="font-size: 80%;">
-		(TODO: breadcrumb here)
-      </div>
-      <h1 class="title">The Sling Engine</h1>
-      <div>
-	    <p><a name="TheSlingEngine-TheSlingEngine"></a></p>
-<h1 id="the-sling-engine">The Sling Engine</h1>
-<p><a name="TheSlingEngine-General"></a></p>
-<h2 id="general">General</h2>
-<ul>
-<li><a href="architecture.html">Architecture</a></li>
-<li><a href="authentication.html">Authentication</a></li>
-</ul>
-<p><a name="TheSlingEngine-RequestHandling"></a></p>
-<h2 id="request-handling">Request Handling</h2>
-<ul>
-<li><a href="dispatching-requests.html">Dispatching Requests</a></li>
-<li><a href="url-decomposition.html">URL decomposition</a></li>
-<li><a href="request-listeners.html">Request Listeners</a></li>
-<li><a href="filters.html">Filters</a></li>
-<li><a href="servlets.html">Servlets and Scripts</a></li>
-<li><a href="errorhandling.html">Errorhandling</a></li>
-<li><a href="request-parameters.html">Request Parameters</a></li>
-</ul>
-<p><a name="TheSlingEngine-Resources"></a></p>
-<h2 id="resources">Resources</h2>
-<ul>
-<li><a href="resources.html">Resources</a></li>
-<li><a href="wrap-or-decorate-resources.html">Wrap or Decorate Resources</a></li>
-<li><a href="mappings-for-resource-resolution.html">Mappings for Resource Resolution</a></li>
-</ul>
-<p><a name="TheSlingEngine-Misc"></a></p>
-<h2 id="misc">Misc</h2>
-<ul>
-<li><a href="adapters.html">Adapters</a></li>
-<li><a href="eventing-and-jobs.html">Eventing and Jobs</a></li>
-</ul>
+<a href="/">Home</a>
       </div>
+   <!--   <h1 class="title">The Sling Engine</h1> -->
+
     
         <div class="trademarkFooter"> 
 		Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.



Mime
View raw message