http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/models.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/models.html b/documentation/bundles/models.html index 157f8bd..25e62eb 100644 --- a/documentation/bundles/models.html +++ b/documentation/bundles/models.html @@ -75,7 +75,7 @@ </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p><!-- TODO reactivate TOC once JBake moves to flexmark-java --> </p> <p>Many Sling projects want to be able to create model objects - POJOs which are automatically mapped from Sling objects, typically resources, but also request objects. Sometimes these POJOs need OSGi services as well.</p> -<h1>Design Goals</h1> +<h1><a href="#design-goals" name="design-goals">Design Goals</a></h1> <ul> <li>Entirely annotation driven. "Pure" POJOs.</li> <li>Use standard annotations where possible.</li> @@ -86,10 +86,9 @@ <li>Support both classes and interfaces.</li> <li>Work with existing Sling infrastructure (i.e. not require changes to other bundles).</li> </ul> -<h1>Basic Usage</h1> +<h1><a href="#basic-usage" name="basic-usage">Basic Usage</a></h1> <p>In the simplest case, the class is annotated with <code>@Model</code> and the adaptable class. Fields which need to be injected are annotated with <code>@Inject</code>:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @@ -98,8 +97,7 @@ public class MyModel { </code></pre> <p>In this case, a property named "propertyName" will be looked up from the Resource (after first adapting it to a <code>ValueMap</code>) and it is injected.</p> <p>For an interface, it is similar:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public interface MyModel { @Inject @@ -107,8 +105,7 @@ public interface MyModel { } </code></pre> <p>Constructor injection is also supported (as of Sling Models 1.1.0):</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject public MyModel(@Named("propertyName") String propertyName) { @@ -130,26 +127,22 @@ public class MyModel { </code></pre> <p>Alternatively it is possible to list all classes individually that are Sling Models classes via the <code>Sling-Model-Classes</code> header.</p> <p>If you use the Sling Models bnd plugin all required bundle headers are generated automatically at build time (see chapter 'Registration of Sling Models classes via bnd plugin' below).</p> -<h1>Client Code</h1> -<h2>adaptTo()</h2> +<h1><a href="#client-code" name="client-code">Client Code</a></h1> +<h2><a href="#adaptto-" name="adaptto-">adaptTo()</a></h2> <p>Client code doesn't need to be aware that Sling Models is being used. It just uses the Sling Adapter framework:</p> -<pre><code>::java -MyModel model = resource.adaptTo(MyModel.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->MyModel model = resource.adaptTo(MyModel.class) </code></pre> <p>Or</p> -<pre><code>::jsp -<sling:adaptTo adaptable="${resource}" adaptTo="org.apache.sling.models.it.models.MyModel" var="model"/> +<pre><code><!-- TODO syntax marker (::jsp) disabled --><sling:adaptTo adaptable="${resource}" adaptTo="org.apache.sling.models.it.models.MyModel" var="model"/> </code></pre> <p>Or</p> -<pre><code>::jsp -${sling:adaptTo(resource, 'org.apache.sling.models.it.models.MyModel')} +<pre><code><!-- TODO syntax marker (::jsp) disabled -->${sling:adaptTo(resource, 'org.apache.sling.models.it.models.MyModel')} </code></pre> <p>As with other AdapterFactories, if the adaptation can't be made for any reason, <code>adaptTo()</code> returns null.</p> -<h2>ModelFactory (since 1.2.0)</h2> +<h2><a href="#modelfactory-since-1-2-0-" name="modelfactory-since-1-2-0-">ModelFactory (since 1.2.0)</a></h2> <p><em>See also <a href="https://issues.apache.org/jira/browse/SLING-3709";>SLING-3709</a></em></p> <p>Since Sling Models 1.2.0 there is another way of instantiating models. The OSGi service <code>ModelFactory</code> provides a method for instantiating a model that throws exceptions. This is not allowed by the Javadoc contract of the adaptTo method. That way <code>null</code> checks are not necessary and it is easier to see why instantiation of the model failed.</p> -<pre><code>::java -try { +<pre><code><!-- TODO syntax marker (::java) disabled -->try { MyModel model = modelFactory.createModel(object, MyModel.class); } catch (Exception e) { // give out error message that the model could not be instantiated. @@ -158,21 +151,19 @@ try { } </code></pre> <p>In addition <code>ModelFactory</code> provides methods for checking whether a given class is a model at all (having the model annotation) or whether a class can be adapted from a given adaptable.</p> -<h1>Other Options</h1> -<h2>Names</h2> +<h1><a href="#other-options" name="other-options">Other Options</a></h1> +<h2><a href="#names" name="names">Names</a></h2> <p>If the field or method name doesn't exactly match the property name, <code>@Named</code> can be used:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @Named("secondPropertyName") private String otherName; } </code></pre> -<h2>Optional and Required</h2> +<h2><a href="#optional-and-required" name="optional-and-required">Optional and Required</a></h2> <p><code>@Inject</code>ed fields/methods are assumed to be required. To mark them as optional, use <code>@Optional</code>:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @Optional @@ -180,8 +171,7 @@ public class MyModel { } </code></pre> <p>If a majority of <code>@Inject</code>ed fields/methods are optional, it is possible (since Sling Models API 1.0.2/Impl 1.0.6) to change the default injection strategy by using adding <code>defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL</code> to the <code>@Model</code> annotation:</p> -<pre><code>::java -@Model(adaptables=Resource.class, defaultInjectionStrategy=DefaultInjectionStrategy.OPTIONAL) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class, defaultInjectionStrategy=DefaultInjectionStrategy.OPTIONAL) public class MyModel { @Inject @@ -190,10 +180,9 @@ public class MyModel { </code></pre> <p>To still mark some fields/methods as being mandatory while relying on <code>defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL</code> for all other fields, the annotation <code>@Required</code> can be used.</p> <p><code>@Optional</code> annotations are only evaluated when using the <code>defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED</code> (which is the default), <code>@Required</code> annotations only if using <code>defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL</code>.</p> -<h2>Defaults</h2> +<h2><a href="#defaults" name="defaults">Defaults</a></h2> <p>A default value can be provided (for Strings & primitives):</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @Default(values="defaultValue") @@ -201,8 +190,7 @@ public class MyModel { } </code></pre> <p>Defaults can also be arrays:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @Default(intValues={1,2,3,4}) @@ -210,8 +198,7 @@ public class MyModel { } </code></pre> <p>OSGi services can be injected:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @@ -219,10 +206,9 @@ public class MyModel { } </code></pre> <p>In this case, the name is not used -- only the class name.</p> -<h2>Collections</h2> +<h2><a href="#collections" name="collections">Collections</a></h2> <p>Lists and arrays are supported by some injectors. For the details look at the table given in <a href="#available-injectors">Available Injectors</a>:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @@ -230,8 +216,7 @@ public class MyModel { } </code></pre> <p>List injection for <em>child resources</em> works by injecting grand child resources (since Sling Models Impl 1.0.6). For example, the class</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { @Inject @@ -248,10 +233,9 @@ public class MyModel { +- address2 </code></pre> <p>In this case, the <code>addresses</code> <code>List</code> will contain <code>address1</code> and <code>address2</code>.</p> -<h2>OSGi Service Filters</h2> +<h2><a href="#osgi-service-filters" name="osgi-service-filters">OSGi Service Filters</a></h2> <p>OSGi injection can be filtered:</p> -<pre><code>::java -@Model(adaptables=SlingHttpServletRequest.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=SlingHttpServletRequest.class) public class MyModel { @Inject @@ -266,10 +250,9 @@ public class MyModel { private List<Servlet> servlets; } </code></pre> -<h2>PostConstruct Methods</h2> +<h2><a href="#postconstruct-methods" name="postconstruct-methods">PostConstruct Methods</a></h2> <p>The <code>@PostConstruct</code> annotation can be used to add methods which are invoked upon completion of all injections:</p> -<pre><code>::java -@Model(adaptables=SlingHttpServletRequest.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=SlingHttpServletRequest.class) public class MyModel { @Inject @@ -286,10 +269,9 @@ public class MyModel { } </code></pre> <p><code>@PostConstruct</code> methods in a super class will be invoked first.</p> -<h2>Via</h2> +<h2><a href="#via" name="via">Via</a></h2> <p>If the injection should be based on a JavaBean property of the adaptable, you can indicate this using the <code>@Via</code> annotation:</p> -<pre><code>::java -@Model(adaptables=SlingHttpServletRequest.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=SlingHttpServletRequest.class) public interface MyModel { // will return request.getResource().adaptTo(ValueMap.class).get("propertyName", String.class) @@ -297,10 +279,9 @@ public interface MyModel { String getPropertyName(); } </code></pre> -<h2>Source</h2> +<h2><a href="#source" name="source">Source</a></h2> <p>If there is ambiguity where a given injection could be handled by more than one injector, the <code>@Source</code> annotation can be used to define which injector is responsible:</p> -<pre><code>::java -@Model(adaptables=SlingHttpServletRequest.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=SlingHttpServletRequest.class) public interface MyModel { // Ensure that "resource" is retrived from the bindings, not a request attribute @@ -308,10 +289,9 @@ public interface MyModel { Resource getResource(); } </code></pre> -<h2>Adaptations</h2> +<h2><a href="#adaptations" name="adaptations">Adaptations</a></h2> <p>If the injected object does not match the desired type and the object implements the <code>Adaptable</code> interface, Sling Models will try to adapt it. This provides the ability to create rich object graphs. For example:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public interface MyModel { @Inject @@ -327,8 +307,7 @@ public interface ImageModel { </code></pre> <p>When a resource is adapted to <code>MyModel</code>, a child resource named <code>image</code> is automatically adapted to an instance of <code>ImageModel</code>.</p> <p>Constructor injection is supported for the adaptable itself. For example:</p> -<pre><code>::java -@Model(adaptables=Resource.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables=Resource.class) public class MyModel { public MyModel(Resource resource) { @@ -341,8 +320,9 @@ public class MyModel { private String propertyName; } </code></pre> -<h2>Sling Validation (since 1.2.0)</h2> -<a name="validation">*See also [SLING-4161](https://issues.apache.org/jira/browse/SLING-4161)*</a> +<h2><a href="#sling-validation-since-1-2-0-" name="sling-validation-since-1-2-0-">Sling Validation (since 1.2.0)</a></h2> +<a name="validation" /> +<p><em>See also <a href="https://issues.apache.org/jira/browse/SLING-4161";>SLING-4161</a></em></p> <p>You can use the attribute <code>validation</code> on the Model annotation to call a validation service on the resource being used by the Sling model. That attribute supports three different values:</p> <table> <thead> @@ -380,10 +360,10 @@ public class MyModel { </table> <p>In case the model is not instantiated an appropriate error message is logged (if <code>adaptTo()</code> is used) or an appropriate exception is thrown (if <code>ModelFactory.createModel()</code> is used).</p> <p>The only implementation for this Sling Models validation service is leveraging <a href="/documentation/bundles/validation.html">Sling Validation</a> and is located in the bundle <a href="https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/models/validation-impl/";>org.apache.sling.models.validation-impl</a>. Validation is only working on models which are adapted from either <code>Resource</code> or <code>SlingHttpServletRequest</code> and if the Sling Validation Bundle is deployed.</p> -<h1>Custom Injectors</h1> +<h1><a href="#custom-injectors" name="custom-injectors">Custom Injectors</a></h1> <p>To create a custom injector, simply implement the <code>org.apache.sling.models.spi.Injector</code> interface and register your implementation with the OSGi service registry. Please refer to the standard injectors in <a href="http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/";>Subversion</a> for examples.</p> <p>Injectors are invoked in order of their service ranking, from lowest to highest. See the table below for the rankings of the standard injectors.</p> -<h1>Annotation Reference</h1> +<h1><a href="#annotation-reference" name="annotation-reference">Annotation Reference</a></h1> <p><code>@Model</code> : declares a model class or interface</p> <p><code>@Inject</code> : marks a field or method as injectable</p> <p><code>@Named</code> : declare a name for the injection (otherwise, defaults based on field or method name).</p> @@ -396,7 +376,7 @@ public class MyModel { <p><code>@Path</code> : only used together with the resource-path injector to specify the path of a resource</p> <p><code>@Exporters</code>/<code>@Exporter</code>/<code>@ExporterOptions</code>/<code>@ExporterOption</code> : See Exporter Framework section below</p> <p>In addition all <a href="#injector-specific-annotations">injector-specific annotations</a>.</p> -<h1>Available Injectors</h1> +<h1><a href="#available-injectors" name="available-injectors">Available Injectors</a></h1> <table> <thead> <tr> @@ -502,7 +482,7 @@ public class MyModel { </tr> </tbody> </table> -<h1>Injector-specific Annotations</h1> +<h1><a href="#injector-specific-annotations" name="injector-specific-annotations">Injector-specific Annotations</a></h1> <p><em>Introduced with <a href="https://issues.apache.org/jira/browse/SLING-3499";>SLING-3499</a> in Sling Models Impl 1.0.6</em></p> <p>Sometimes it is desirable to use customized annotations which aggregate the standard annotations described above. This will generally have the following advantages over using the standard annotations:</p> <ul> @@ -571,28 +551,27 @@ public class MyModel { </tr> </tbody> </table> -<h2>Hints</h2> +<h2><a href="#hints" name="hints">Hints</a></h2> <p>Those annotations replace <code>@Via</code>, <code>@Filter</code>, <code>@Named</code>, <code>@Optional</code>, <code>@Required</code>, <code>@Source</code> and <code>@Inject</code>. Instead of using the deprecated annotation element <code>optional</code> you should rather use <code>injectionStrategy</code> with the values <code>DEFAULT</code>, <code>OPTIONAL</code> or <code>REQUIRED</code> (see also <a href="https://issues.apache.org/jira/browse/SLING-4155";>SLING-4155</a>). <code>@Default</code> may still be used in addition to the injector-specific annotation to set default values. All elements given above are optional.</p> -<h2>Custom Annotations</h2> +<h2><a href="#custom-annotations" name="custom-annotations">Custom Annotations</a></h2> <p>To create a custom annotation, implement the <code>org.apache.sling.models.spi.injectorspecific.StaticInjectAnnotationProcessorFactory</code> interface. This interface may be implemented by the same class as implements an injector, but this is not strictly necessary. Please refer to the injectors in <a href="http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/";>Subversion</a> for examples.</p> -<h1>Specifying an Alternate Adapter Class (since 1.1.0)</h1> +<h1><a href="#specifying-an-alternate-adapter-class-since-1-1-0-" name="specifying-an-alternate-adapter-class-since-1-1-0-">Specifying an Alternate Adapter Class (since 1.1.0)</a></h1> <p>By default, each model class is registered using its own implementation class as adapter. If the class has additional interfaces this is not relevant.</p> <p>The <code>@Model</code> annotations provides an optional <code>adapters</code> attribute which allows specifying under which type(s) the model implementation should be registered in the Models Adapter Factory. Prior to <em>Sling Models Impl 1.3.10</em> only the given class names are used as adapter classes, since 1.3.10 the implementation class is always being registered implicitly as adapter as well (see <a href="https://issues.apache.org/jira/browse/SLING-6658";>SLING-6658</a>). With this attribute it is possible to register the model to one (or multiple) interfaces, or a superclass. This allows separating the model interface from the implementation, which makes it easier to provide mock implementations for unit tests as well.</p> <p>Example:</p> -<pre><code>::java -@Model(adaptables = Resource.class, adapters = MyService.class) +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptables = Resource.class, adapters = MyService.class) public class MyModel implements MyService { // injects fields and implements the MyService methods } </code></pre> <p>In this example a <code>Resource</code> can be adapted to a <code>MyService</code> interface, and the Sling Models implementation instantiates a <code>MyModel</code> class for this.</p> <p>It is possible to have multiple models implementing the same interface. By default Sling Models will just take the first one ordered alphabetically by the class name. Applications can provide an OSGi service implementing the <code>ImplementationPicker</code> SPI interface which could use context to determine which implementation can be chosen, e.g. depending an a tenant or content path context. If multiple implementations of the <code>ImplementationPicker</code> interface are present, they are queried one after another in order of their service ranking property, the first one that picks an implementation wins.</p> -<h1>Associating a Model Class with a Resource Type (since 1.3.0)</h1> +<h1><a href="#associating-a-model-class-with-a-resource-type-since-1-3-0-" name="associating-a-model-class-with-a-resource-type-since-1-3-0-">Associating a Model Class with a Resource Type (since 1.3.0)</a></h1> <p>The <code>@Model</code> annotation provides an optional <code>resourceType</code> attribute which allows for model classes to be associated with one or more resource types. This is used in three different ways.</p> <p>In the case of multiple model classes implementing the same interface, the class with the "closest" resource type will be used when adapting to the interface.</p> <p>The <code>ModelFactory</code> service interface has methods <code>Object getModelFromResource(Resource)</code> and <code>Object getModelFromRequest(SlingHttpServletRequest)</code> which will dynamically determine the adapter class based on the <code>Resource</code> using its type. In the case of the <code>SlingHttpServletRequest</code> method, it uses the request's <code>Resource</code> object (i.e. by calling <code>request.getResource()</code>)</p> <p>The resource type is also used as part of the Exporter framework (see next section).</p> -<h1>Exporter Framework (since 1.3.0)</h1> +<h1><a href="#exporter-framework-since-1-3-0-" name="exporter-framework-since-1-3-0-">Exporter Framework (since 1.3.0)</a></h1> <p>Sling Models objects can be exported to arbitrary Java objects through the Sling Models Exporter framework. Model objects can be programatically exported by calling the <code>ModelFactory</code> method <code>exportModel()</code>. This method takes as its arguments:</p> <ul> <li>the model object</li> @@ -602,16 +581,14 @@ public class MyModel implements MyService { </ul> <p>The exact semantics of the exporting will be determined by an implementation of the <code>ModelExporter</code> service interface. Sling Models currently includes a single exporter, using the Jackson framework, which is capable of serializing models as JSON or transforming them to <code>java.util.Map</code> objects.</p> <p>In addition, model objects can have servlets automatically registered for their resource type (if it is set) using the <code>@Exporter</code> annotation. For example, a model class with the annotation</p> -<pre><code>::java -@Model(adaptable = Resource.class, resourceType = "myco/components/foo") +<pre><code><!-- TODO syntax marker (::java) disabled -->@Model(adaptable = Resource.class, resourceType = "myco/components/foo") @Exporter(name = "jackson", extensions = "json") </code></pre> <p>results in the registration of a servlet with the resource type and extension specified and a selector of 'model' (overridable through the <code>@Exporter</code> annotation's <code>selector</code> attribute). When this servlet is invoked, the <code>Resource</code> will be adapted to the model, exported as a <code>java.lang.String</code> (via the named Exporter) and then returned to the client.</p> -<h1>Registration of Sling Models classes via bnd plugin</h1> +<h1><a href="#registration-of-sling-models-classes-via-bnd-plugin" name="registration-of-sling-models-classes-via-bnd-plugin">Registration of Sling Models classes via bnd plugin</a></h1> <p>With the Sling Models bnd plugin it is possible to automatically generated the necessary bundle header to register the Sling Models classes contained in the Maven bundle project - either with maven-bundle-plugin or with bnd-maven-plugin. By default the plugin generates a <code>Sling-Model-Classes</code> header (only compatible with Sling Models Impl since version 1.3.4, see <a href="https://issues.apache.org/jira/browse/SLING-6308";>SLING-6308</a>).</p> <p>Example configuration:</p> -<pre><code>#!xml -<plugin> +<pre><code><!-- TODO syntax marker (#!xml) disabled --><plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <extensions>true</extensions> @@ -631,8 +608,7 @@ public class MyModel implements MyService { </code></pre> <p>If a <code>Sling-Model-Packages</code> or <code>Sling-Model-Classes</code> was already manually defined for the bundle the bnd plugin does nothing. So if you want to migrate an existing project to use this plugin remove the existing header definitions.</p> <p>If you want to generate a bundle header compliant with Sling Models < 1.3.4 (i.e. <code>Sling-Model-Packages</code>) you need to specify the attribute <code>generatePackagesHeader=true</code>. An example configuration looks like this</p> -<pre><code>#!xml -<configuration> +<pre><code><!-- TODO syntax marker (#!xml) disabled --><configuration> <instructions> <_plugin>org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true</_plugin> </instructions>
http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/nosql-resource-providers.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/nosql-resource-providers.html b/documentation/bundles/nosql-resource-providers.html index 581e80a..20fda95 100644 --- a/documentation/bundles/nosql-resource-providers.html +++ b/documentation/bundles/nosql-resource-providers.html @@ -74,7 +74,7 @@ NoSQL Resource Providers (org.apache.sling.nosql) </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p><!-- TODO reactivate TOC once JBake moves to flexmark-java --> </p> -<h2>Introduction</h2> +<h2><a href="#introduction" name="introduction">Introduction</a></h2> <p>Apache Sling provides resource-based access to NoSQL document stores like MongoDB and Couchbase via its Resource API using the NoSQL resource providers. This is possible in combination with a JCR-based repository (e.g. only on a special path in the resource tree), or a only persistence for the whole resource tree depending on the resource provider configuration.</p> <p>The general concept of retrieving from and storing resource data in NoSQL document stores is the same independently from the NoSQL product used:</p> <ul> @@ -87,7 +87,7 @@ </ul> <p>All these general features are implemented in an abstraction layer called <a href="https://github.com/apache/sling/tree/trunk/contrib/nosql/generic";>"Apache Sling NoSQL Generic Resource Provider"</a>, which is used by the resource provider implementations per NoSQL product. Those implementation than only implement a thin "adapter" which maps the resource data to the NoSQL product-specific storage formats and query capabilities, without having to care about all the complex resource provider handling.</p> <p>This generic resource provider also contains a set of integration tests covering the most relevant resource read- and write usecases which can be used to test a NoSQL product-specific resource provider implementation and the underlying NoSQL database.</p> -<h2>MongoDB NoSQL Resource Provider</h2> +<h2><a href="#mongodb-nosql-resource-provider" name="mongodb-nosql-resource-provider">MongoDB NoSQL Resource Provider</a></h2> <p>Resource provider for <a href="https://www.mongodb.org/";>MongoDB</a> NoSQL database.</p> <p>Tested with MongoDB Server 3.0.6 and MongoDB Java Driver 3.1.1.</p> <p>Configuration example:</p> @@ -100,7 +100,7 @@ <p>See Apache Felix OSGi console for detailed documentation of the parameters. All resource data is stored in one Collection of one MongoDB database. Each resource is stored as a document with the path stored in an "_id" property.</p> <p>Source code: <a href="https://github.com/apache/sling/tree/trunk/contrib/nosql/mongodb-resourceprovider";>Apache Sling NoSQL MongoDB Resource Provider</a></p> <p>Please note: there is an <a href="https://github.com/apache/sling/tree/trunk/contrib/extensions/mongodb";>alternative MongoDB resource provider implementation</a> from 2012 which has less features, a slightly different concept for storing resource data (in multiple collections), and it does not use the "Generic Resource Provider".</p> -<h2>Couchbase NoSQL Resource Provider</h2> +<h2><a href="#couchbase-nosql-resource-provider" name="couchbase-nosql-resource-provider">Couchbase NoSQL Resource Provider</a></h2> <p>Resource provider for <a href="http://www.couchbase.com/";>Couchbase</a> NoSQL database.</p> <p>Tested with Couchbase Server 4.0.0 and Couchbase Java SDK 2.2.4. Please note: Couchbase 4 or higher is mandatory because N1QL support is required.</p> <p>Configuration example:</p> @@ -116,7 +116,7 @@ org.apache.sling.nosql.couchbase.client.CouchbaseClient.factory.config-default <p>See Apache Felix OSGi console for detailed documentation of the parameters. All resource data is stored in one Couchbase bucket. Each resource is stored as a document with the path as key.</p> <p>Source code: <a href="https://github.com/apache/sling/tree/trunk/contrib/nosql/couchbase-resourceprovider";>Apache Sling NoSQL Couchbase Resource Provider</a></p> <p>The resource provider requires and additional bundle <a href="https://github.com/apache/sling/tree/trunk/contrib/nosql/couchbase-client";>Apache Sling NoSQL Couchbase Client</a> which wraps the Couchbase Java SDK (which itself is not an OSGi bundle), and ensures that the Couchbase Environment instance is used as a singleton in the VM.</p> -<h2>Example Launchpad</h2> +<h2><a href="#example-launchpad" name="example-launchpad">Example Launchpad</a></h2> <p>An example launchpad is provided that contains the NoSQL resource providers configured as main resource provider at <code>/</code>.</p> <p>Source code: <a href="https://github.com/apache/sling/tree/trunk/contrib/nosql/launchpad";>Apache Sling NoSQL Launchpad</a></p> <p>See README for details how to start the launchpad.</p></section></div></div> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/org-apache-sling-junit-bundles.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/org-apache-sling-junit-bundles.html b/documentation/bundles/org-apache-sling-junit-bundles.html index b0a5609..c4a2570 100644 --- a/documentation/bundles/org-apache-sling-junit-bundles.html +++ b/documentation/bundles/org-apache-sling-junit-bundles.html @@ -74,7 +74,7 @@ JUnit server-side testing support bundles </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p>This is an overview of the Sling bundles that provide support for server-side JUnit tests. </p> <p>The Maven modules below <a href="https://svn.apache.org/repos/asf/sling/trunk/testing/samples";><code>testing/samples</code></a> provide different examples including HTTP-based and server-side teleported tests in a bundle module, running against a full Sling instance setup in the same Maven module.</p> -<h2>org.apache.sling.junit.core: server-side JUnit tests support</h2> +<h2><a href="#org-apache-sling-junit-core-server-side-junit-tests-support" name="org-apache-sling-junit-core-server-side-junit-tests-support">org.apache.sling.junit.core: server-side JUnit tests support</a></h2> <p>This bundle provides a <code>JUnitServlet</code> that runs JUnit tests found in bundles. </p> <div class="warning"> 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 `/system` path should not be accessible to website visitors anyway. @@ -85,7 +85,7 @@ For tighter integration with Sling, the alternate `SlingJUnitServlet` is registe <p>To make tests available to that servlet, the bundle that contains them must point to them with a <code>Sling-Test-Regexp</code> bundle header that defines a regular expression that matches the test class names, like for example:</p> <pre><code>Sling-Test-Regexp=com.example.*ServerSideTest </code></pre> -<h3>The TeleporterRule</h3> +<h3><a href="#the-teleporterrule" name="the-teleporterrule">The TeleporterRule</a></h3> <p>The <code>TeleporterRule</code> supplied by this bundle (since V1.0.12) makes it easy to write such tests, as it takes care of all the mechanics of </p> <ol> <li>creating the test bundle including all necessary classes for execution</li> @@ -130,15 +130,15 @@ public final TeleporterRule teleporter = <p>which will embed all resources found under <code>/foo</code> as well as the <code>resource.txt</code> in the test bundle, making them available to the server-side tests.</p> <p>This teleporter mechanism is used in our integration tests, search for <code>TeleporterRule</code> in there for examples or look at the <a href="https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/teleporter";><code>integrationtest.teleporter</code></a> package. </p> <p>As I write this the teleporter mechanism is quite new, I suspect there might be some weird interactions between things like <code>@AfterClass</code>, custom test runners and this mechanism but it works well to a growing number of tests in our <code>launchpad/integration-tests</code> module. Moving to JUnit <code>Rules</code> as much as possible, and combining them using JUnit's <code>RuleChain</code>, should help work around such limitations if they arise.</p> -<h3>More details on the JUnitServlet</h3> +<h3><a href="#more-details-on-the-junitservlet" name="more-details-on-the-junitservlet">More details on the JUnitServlet</a></h3> <p>To try the JUnitServlet interactively, you can install a bundle that contains tests and a <code>Sling-Test-Regexp</code> bundle header that points to them, as described above. Or use the <code>TeleporterRule</code> and set a breakpoint in the tests execution, when the test bundle in installed and listed by the test servlet.</p> <p>To list the available tests, open <code>/system/sling/junit/</code> in your browser. 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 <code>/system/sling/junit/org.apache.sling.junit.remote.html</code></p> <p>The JUnitServlet provides various output formats, including in particular JSON, see <code>/system/sling/junit/.json</code> for example.</p> -<h2>org.apache.sling.junit.teleporter: client-side TeleporterRule support</h2> +<h2><a href="#org-apache-sling-junit-teleporter-client-side-teleporterrule-support" name="org-apache-sling-junit-teleporter-client-side-teleporterrule-support">org.apache.sling.junit.teleporter: client-side TeleporterRule support</a></h2> <p>This module provides the <code>ClientSideTeleporter</code> which the <code>TeleporterRule</code> uses to package the server-side tests in bundles that's installed temporarily on the test server. Almost all steps described above in <a href="#the-teleporterrule">The TeleporterRule</a> are being performed by this module.</p> <p>This module is not a bundle, as it's used on the client only, as a dependency when running the tests.</p> -<h3>TeleporterRule.Customizer</h3> +<h3><a href="#teleporterrule-customizer" name="teleporterrule-customizer">TeleporterRule.Customizer</a></h3> <p>A <code>TeleporterRule.Customizer</code> is used to setup the <code>ClientSideTeleporter</code>. That customizer is instantiated dynamically based on a String passed to the <code>TeleporterRule.forClass</code> method as 2nd parameter. As an example from our <code>launchpad/integration-tests</code> module, this call</p> <pre><code>TeleporterRule.forClass(getClass(), "Launchpad:author"); </code></pre> @@ -147,7 +147,7 @@ public final TeleporterRule teleporter = <p>Using Strings for customization reduces the coupling with the <code>junit.core</code> bundle, as it does not need to know those classes which are used only on the client side when running tests. </p> <p>If <code>TeleporterRule.forClass(getClass())</code> is used (the method without an additional 2nd parameter) the default customizer is used (<a href="https://issues.apache.org/jira/browse/SLING-5677";>SLING-5677</a>, since version 1.0.8). </p> <p>The following customizers are currently used in Sling</p> -<h3>Default Customizer</h3> +<h3><a href="#default-customizer" name="default-customizer">Default Customizer</a></h3> <p><em><a href="https://svn.apache.org/repos/asf/sling/trunk/testing/junit/teleporter/src/main/java/org/apache/sling/testing/teleporter/client/DefaultPropertyBasedCustomizer.java";>DefaultPropertyBasedCustomizer.java</a></em> is used by default when no other customizer is referenced in <code>TeleporterRule.forClass(getClass())</code>. It relies on the following system properties:</p> <table> <thead> @@ -260,15 +260,15 @@ public final TeleporterRule teleporter = </tbody> </table> <p>The provisioning of an appropriate instance can be done with the <a href="/documentation/development/slingstart.html">slingstart-maven-plugin</a>. An example for that is given at <a href="https://svn.apache.org/viewvc/sling/trunk/testing/samples/module-with-it";><code>testing/samples/module-with-it</code></a>. Since <code>slingstart-maven-plugin</code> 1.5.0 it is possible to bootstrap a Sling Server from a <code>model.txt</code> below <code>src/test/provisioning</code> independent of the packaging (see <a href="https://issues.apache.org/jira/browse/SLING-6068";>SLING-6068</a>).</p> -<h4>LaunchpadCustomizer</h4> +<h4><a href="#launchpadcustomizer" name="launchpadcustomizer">LaunchpadCustomizer</a></h4> <p>The <em><a href="https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/junit/teleporter/customizers/LaunchpadCustomizer.java";><code>LaunchpadCustomizer.java</code></a></em> only verifies that a Sling instance is ready at a given port and configures the <code>ClientSideTeleporter</code> to deploy to <code>http://localhost:8888</code> with the credentials <code>admin</code>:<code>admin</code>. <code>LaunchpadCustomizer</code> uses the <code>HttpTestBase</code> therefore some parameters are customizable through system properties. There is no bootstrapping of an instance done here, so this must be done separately!</p> <h4>BWIT_TeleporterCustomizer</h4> <p>The <em><a href="http://svn.apache.org/viewvc/sling/trunk/testing/samples/bundle-with-it/src/test/java/org/apache/sling/junit/teleporter/customizers/BWIT_TeleporterCustomizer.java";><code>BWIT_TeleporterCustomizer.java</code></a></em> relies on <code>SlingTestBase</code> to set the server's base url and credentials. Additionally the test bundle is adjusted so that the API is not included in it (but rather referenced from another bundle). The bootstrapping of the Sling instance is tweaked through system properties which are desribed <a href="http://labs.6dglobal.com/blog/2013-06-05/creating-integration-tests-apache-sling/";>here</a> and implicitly done by the customizer itself.</p> <p>Those should give you an overview on what can be done with a customizer and decide whether you need to write your own one or using the default customizer is just enough.</p> -<h2>org.apache.sling.junit.healthcheck: run JUnit tests as Sling Health Checks</h2> +<h2><a href="#org-apache-sling-junit-healthcheck-run-junit-tests-as-sling-health-checks" name="org-apache-sling-junit-healthcheck-run-junit-tests-as-sling-health-checks">org.apache.sling.junit.healthcheck: run JUnit tests as Sling Health Checks</a></h2> <p>This bundle allows JUnit tests to run as <a href="/documentation/bundles/sling-health-check-tool.html">Sling Health Checks</a>, which can be useful when defining smoke tests for example, allowing them to be used both at build time and run time.</p> <p>See the <code>JUnitHealthCheck</code> class for details. </p> -<h2>org.apache.sling.junit.scriptable: scriptable server-side tests</h2> +<h2><a href="#org-apache-sling-junit-scriptable-scriptable-server-side-tests" name="org-apache-sling-junit-scriptable-scriptable-server-side-tests">org.apache.sling.junit.scriptable: scriptable server-side tests</a></h2> <p>This bundle allows Sling scripts to be executed from the <code>JUnitServlet</code> as JUnit tests, as follows:</p> <ul> <li>A node that has the <code>sling:Test</code> mixin is a scriptable test node.</li> @@ -296,7 +296,7 @@ TEST_PASSED ] </code></pre> <p>Test failures would be included in this JSON representation - you can test that by modifying the script to fail and making the same request again. </p> -<h2>org.apache.sling.junit.remote: obsolete</h2> +<h2><a href="#org-apache-sling-junit-remote-obsolete" name="org-apache-sling-junit-remote-obsolete">org.apache.sling.junit.remote: obsolete</a></h2> <p>The <code>org.apache.sling.junit.remote</code> bundle provides utilities to run server-side JUnit tests, but using the newer <code>TeleporterRule</code> described above is much simpler. As a result, this bundle should only be needed for existing tests that were written using its mechanisms. </p></section></div></div> <div class="footer"> <div class="trademarkFooter"> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/osgi-installer.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/osgi-installer.html b/documentation/bundles/osgi-installer.html index a42d41a..7652b72 100644 --- a/documentation/bundles/osgi-installer.html +++ b/documentation/bundles/osgi-installer.html @@ -72,27 +72,27 @@ </div> <div class="main"> <div class="breadcrumbs"><a href="/ng/">Home</a> » <a href="/ng/documentation.html">Documentation</a> » <a href="/ng/documentation/bundles.html">Bundles</a> » </div> <h1> OSGi Installer - </h1><div class="row"><div class="small-12 columns"><section class="wrap"><h1>Overview</h1> + </h1><div class="row"><div class="small-12 columns"><section class="wrap"><h1><a href="#overview" name="overview">Overview</a></h1> <p>The OSGi installer is a central service for handling installs, updates and uninstall of "artifacts". By default, the installer supports bundles and has an extension for handling configurations for the OSGi configuration admin.</p> <p><img src="/documentation/bundles/Slide14.jpg" alt="Apache Sling OSGI Installer Diagram" /></p> <p>The OSGi installer itself is "just" the central service managing the tasks and states of the artifacts. The artifacts can be provided through various providers, e.g. through a file system provider reading artifacts from configured directories or the jcr provider reading artifacts from a JCR repository.</p> <p>A provider is just scanning for artifacts and their removal. It informs the OSGi installer about new artifacts and removed artifacts. The provider itself has usually no knowledge about the contents of an artifact. It does not know about bundles, configurations etc.</p> <p>As the OSGi installer itself is not performing the actual install, update or removal of an artifact, its possible to install transformers and installer factories. A transformer inspects the artifacts and tries to detect its type. By default, detecting of bundles and configurations is supported. The final service is an installer factory creating the actual task, like install this bundle, update that bundle etc.</p> <p>It's possible to add own providers, transformers and installer factories to support custom scenarios.</p> -<h2>API</h2> +<h2><a href="#api" name="api">API</a></h2> <p>The installer API is defined by the <code>org.apache.sling.installer.api</code> package of the <a href="http://svn.apache.org/repos/asf/sling/trunk/installer/core/";>org.apache.sling.installer.core</a> module. The main interface is the <code>OsgiInstaller</code> with which installable resources can be registered.</p> <p>The [installer integration tests][1] module can be useful to understand the details of how the installer works.</p> -<h2>Artifact Handling</h2> +<h2><a href="#artifact-handling" name="artifact-handling">Artifact Handling</a></h2> <p>Once an artifact is detected by a transformer, it gets a unique id. By default a bundle gets the symbolic name as the unique identifier and a configuration the PID. In addition to this id, an artifact gets a priority information from the provider. The priority is used if an artifact with the same id is provided several times from different locations. For example if a file system provider is scanning two directories and an artifact with the same id (like a configuration) is added to both directories, one should have precedence over the other. This is handled by the priority.</p> <p>Artifacts with the same unique id are grouped and then sorted by priority and maybe other artifact dependent metadata like the bundle version. Only the first artifact in this sorted group is tried to be applied!</p> -<h2>Bundle Handling</h2> +<h2><a href="#bundle-handling" name="bundle-handling">Bundle Handling</a></h2> <p>In general, the OSGi installer always tries to install the highest version of a bundle if several bundles with the same symbolic name are provided. In this case higher version wins over priority. If an installed bundle is removed by a provider, for example deleted in the repository, the OSGi installer uninstall the bundle. If a bundle is removed from a provider which is currently not installed, this has no effect at all. If an installed bundle is removed and another version of this bundle is provided (a lower version), than this one is installed instead. This is basically a downgrade of the bundle. If a bundle is installed and a higher version is provided, an upgrade is performed. If an installed bundle is managed via any other OSGi tooling, like uninstalling it through the web console, the OSGi installer does no action at all!</p> <p>If a failure occurs during bundle installation or update, the OSGi installer will retry this as soon as another bundle has been installed. The common use case is an application installation with several bundles where one bundle depends on another. As they are installed in arbitrary order, this mechanism ensures that in the end all bundles are properly wired and installed.</p> <p>When all artifacts have been processed (either install, update or delete), a package refresh is automatically called.</p> -<h3>Versions and Snapshots</h3> +<h3><a href="#versions-and-snapshots" name="versions-and-snapshots">Versions and Snapshots</a></h3> <p>The OSGi installer asumes that a symbolic name and version (not a snapshot version) uniquely identifies a bundle. Obviously this is a common development requirement that a released version of an artifact never changes over time. Therefore, once a bundle with a specific version is installed, it will not be reinstalled if the corresponding artifact changes. For example, if bundle A with version 1.0 is put into the JCR repository, it gets installed. If now this jar in the repository is overwritten either with the same contents or with a different one, and this new artifact has again A as the symbolic name and version set to 1.0, nothing will happen as this exact bundle is already installed.</p> <p>During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT (using the Maven convention). If a bundle with a snapshot version is changed, it gets updated by the OSGI installer.</p> -<h2>Start Level Handling</h2> +<h2><a href="#start-level-handling" name="start-level-handling">Start Level Handling</a></h2> <p>The OSGi installer supports handling of start levels for bundles. If the provided bundle artifacts contain a start level information the bundle is installed with that start level, otherwise the default start level is used. Therefore, for initial provisioning to make use of start levels, the OSGi installer and the corresponding provider (see below) should run at a very low start level, probably at 1. This ensure that the bundles with a start level are started with respect to the start level.</p> <p>When an update of bundles is performed through the installer, by default the installer stays in the current start level and updates the bundles. However, if bundles at low start levels are affected, this might result in a lot of churn going on. Therefore, the OSGi installer can be configured to use a more intelligent start level handling:</p> <ul> @@ -102,24 +102,24 @@ <li>the bundles are updated/installed</li> <li>the start level is increased to the previous level</li> </ul> -<h2>Plugins</h2> -<h3>Factories</h3> +<h2><a href="#plugins" name="plugins">Plugins</a></h2> +<h3><a href="#factories" name="factories">Factories</a></h3> <p>An installer factory provides support for a specific artifact type, like a configuration or a deployment package etc.</p> <ul> <li><a href="/documentation/bundles/configuration-installer-factory.html">Configuration Installer Factory</a></li> <li><a href="/documentation/bundles/subsystem-installer-factory.html">Subsystem Installer Factory</a></li> </ul> -<h3>Providers</h3> +<h3><a href="#providers" name="providers">Providers</a></h3> <p>A provider provides artifacts, e.g. by scanning a directory or a database etc.</p> <ul> <li><a href="/documentation/bundles/file-installer-provider.html">File Installer Provider</a></li> <li><a href="/documentation/bundles/jcr-installer-provider.html">JCR Installer Provider</a></li> </ul> -<h2>Health Check</h2> +<h2><a href="#health-check" name="health-check">Health Check</a></h2> <p>The OSGi installer provides a <a href="/documentation/bundles/sling-health-check-tool.html">Sling Health Check</a> which validates that the processed OSGi installer resources have the correct state (<a href="https://issues.apache.org/jira/browse/SLING-5888";>SLING-5888</a>). By default it will only check resources with a URL prefix <code>jcrinstall:/apps/</code>, so only the resources being provided through the <a href="/documentation/bundles/jcr-installer-provider.html">JCR Installer Provider</a> initially located below the repository resource <code>/apps/</code> are considered. The health check will fail in the following cases:</p> -<h3>Bundles Installation Failure</h3> +<h3><a href="#bundles-installation-failure" name="bundles-installation-failure">Bundles Installation Failure</a></h3> <p>The checked bundle was not installed because it has been installed in a newer version through some other means (e.g. manually through the Felix Web Console or by another provider. For further details please review the OSGi Installer console at <code>/system/console/osgi-installer</code> and check for all bundles with the given symbolic name (=OSGi installers resource id) and the according URL.</p> -<h3>Configuration Installation Failure</h3> +<h3><a href="#configuration-installation-failure" name="configuration-installation-failure">Configuration Installation Failure</a></h3> <p>The checked configuration was not installed because it has either been overwritten manually in the Felix Web Console or is installed by some non-checked provider (which has a higher priority). To revert manually overwritten configurations just go to <code>/system/console/configMgr</code> and delete the according configuration. That way the OSGi installer should automatically create a new configuration for the same PID based on the configuration provided by some provider with the highest prio. In case another non-checked provider has provided already a configuration you can see from where it has been installed by looking at the OSGi Installer console at <code>/system/console/osgi-installer</code> and look for all configurations with the given PID.</p></section></div></div> <div class="footer"> <div class="trademarkFooter"> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html b/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html index f4e4b20..11ab84d 100644 --- a/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html +++ b/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html @@ -74,7 +74,7 @@ Output Rewriting Pipelines (org.apache.sling.rewriter) </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p>The Apache Sling Rewriter is a module for rewriting the output generated by a usual Sling rendering process. Some possible use cases include rewriting or checking all links in an HTML page, manipulating the HTML page, or using the generated output as the base for further transformation. An example of further transformation is to use XSLT to transform rendered XML to some output format like HTML or XSL:FO for generating PDF.</p> <p>For supporting these use cases, the rewriter uses the concept for a processor. The processor is a component that is injected through a servlet filter into the response. By implementing the <em>Processor</em> interface one is able to rewrite the whole response in one go. A more convenient way of processing the output is by using a so called pipeline; the Apache Sling rewriter basically uses the same concept as the famous Apache Cocoon: an XML based pipeline for further post processing of the output. The pipeline is based on SAX events.</p> -<h2>SAX Pipelines</h2> +<h2><a href="#sax-pipelines" name="sax-pipelines">SAX Pipelines</a></h2> <p>The rewriter allows to configure a pipeline for post processing of the generated response. Depending on how the pipeline is assembled the rewriting process might buffer the whole output in order to do proper post processing - for example this is required if an HTML response is "transformed" to XHTML or if XSLT is used to process the response.</p> <p>As the pipeline is based on SAX events, there needs to be a component that generates these events and sends them through the pipeline. By default the Sling rendering scripts write to an output stream, so there is a need to parse this output and generate the SAX events.</p> <p>The first component in the pipeline generating the initial SAX events is called a generator. The generator gets the output from Sling, generates SAX events (XML), and streams these events into the pipeline. The counterpart of the generator is the serializer which builds the end of the pipeline. The serializer collects all incomming SAX events, transforms them into the required response by writing into output stream of the response.</p> @@ -96,21 +96,19 @@ </ul> <p>As you can see from the configuration there are several possibilities to define when a pipeline should be used for a response, like paths, extensions, content types, or resource types. It is possible to specify several of them at once. In this case all conditions must be met.</p> <p>If a component needs a configuration, the configuration is stored in a child node which name is <em>{componentType}-{name}</em>, e.g. to configure the HTML generator (named <em>html-generator</em>), the node should have the name <em>generator-html-generator</em>. In the case that the pipeline contains the same transformer several times, the configuration child node should have the formant <em>{componentType}-{index}</em> where index is the index of the transformer starting with 1. For example if you have a pipeline with the following transformers, xslt, html-cleaner, xslt, link-checker, then the configuration nodes should be named <em>transformer-1</em> (for the first xslt), <em>transformer-html-cleaner</em>, <em>transformer-3</em> (for the second xslt), and <em>transformer-link-checker</em>.</p> -<h3>Default Pipeline</h3> +<h3><a href="#default-pipeline" name="default-pipeline">Default Pipeline</a></h3> <p>The default pipeline is configured for the <em>text/html</em> mime type and the <em>html</em> extensions and consists of the <em>html-generator</em> as the generator, and the <em>html-serializer</em> for generating the final response. As the HTML generated by Sling is not required to be valid XHTML, the HTML parser is using an HTML parser to create valid SAX events. In order to perform this, the generator needs to buffer the whole response first.</p> -<h2>Implementing Pipeline Components</h2> +<h2><a href="#implementing-pipeline-components" name="implementing-pipeline-components">Implementing Pipeline Components</a></h2> <p>Each pipeline component type has a corresponding Java interface (Generator, Transformer, and Serializer) together with a factory interface (GeneratorFactory, TransformerFactory, and SerializerFactory). When implementing such a component, both interfaces need to be implemented. The factory has only one method which creates a new instance of that type for the current request. The factory has to be registered as a service. For example if you're using the Maven SCR plugin, it looks like this:</p> -<pre><code>::java [email protected] metatype="no" +<pre><code><!-- TODO syntax marker (::java) disabled -->@scr.component metatype="no" @scr.service interface="TransformerFactory" @scr.property value="pipeline.type" value="validator" </code></pre> <p>The factory needs to implement the according interface and should be registered as a service for this factory interface (this is a plain service and not a factory service in the OSGi sense). Each factory gets a unique name through the <em>pipeline.type</em> property. The pipeline configuration in the repository just references this unique name (like validator).</p> -<h2>Extending the Pipeline</h2> +<h2><a href="#extending-the-pipeline" name="extending-the-pipeline">Extending the Pipeline</a></h2> <p>With the possibilities from above, it is possible to define new pipelines and add custom components to the pipeline. However, in some cases it is required to just add a custom transformer to the existing pipeline. Therefore the rewriting can be configured with pre and post transformers that are simply added to each configured pipeline. This allows a more flexible way of customizing the pipeline without changing/adding a configuration in the repository.</p> <p>The approach here is nearly the same. A transformer factory needs to be implemented, but instead of giving this factory a unique name, this factory is marked as a global factory:</p> -<pre><code>::java [email protected] metatype="no" +<pre><code><!-- TODO syntax marker (::java) disabled -->@scr.component metatype="no" @scr.service interface="TransformerFactory" @scr.property name="pipeline.mode" value="global" @scr.property name="service.ranking" value="RANKING" type="Integer" @@ -118,15 +116,14 @@ <p><em>RANKING</em> is an integer value (don't forget the type attribute otherwise the ranking is interpreted as zero!) specifying where to add the transformer in the pipeline. If the value is less than zero the transformer is added at the beginning of the pipeline right after the generator. If the ranking is equal or higher as zero, the transformer is added at the end of the pipeline before the serializer.</p> <p>The <em>TransformerFactory</em> interface has just one method which returns a new transformer instance. If you plan to use other services in your transformer you might declare the references on the factory and pass in the instances into the newly created transformer.</p> <p>Since the transformer carries information about the current response it is not advisable to reuse the same transformer instance among multiple calls of <code>TransformerFactory.createTransformer</code>.</p> -<h2>Implementing a Processor</h2> +<h2><a href="#implementing-a-processor" name="implementing-a-processor">Implementing a Processor</a></h2> <p>A processor must conform to the Java interface <em>org.apache.sling.rewriter.Processor</em>. It gets initializd (method <em>init</em>) with the <em>ProcessingContext</em>. This context contains all necessary information for the current request (especially the output writer to write the rewritten content to). The <em>getWriter</em> method should return a writer where the output is written to. When the output is written or an error occured <em>finished</em> is called.</p> <p>Like the pipeline components a processor is generated by a factory which has to be registered as a service factory, like this:</p> -<pre><code>::java [email protected] metatype="no" +<pre><code><!-- TODO syntax marker (::java) disabled -->@scr.component metatype="no" @scr.service interface="ProcessorFactory" @scr.property value="pipeline.type" value="uniqueName" </code></pre> -<h2>Configuring a Processor</h2> +<h2><a href="#configuring-a-processor" name="configuring-a-processor">Configuring a Processor</a></h2> <p>The processors can be configured in the repository as a child node of <em>/apps/APPNAME/config/rewriter</em> (or libs or any configured search path). Each node can have the following properties:</p> <ul> <li>processorType - the type of the processor (required) - this is the part from the scr factory information after the slash (in the example above this is <em>uniqueName</em>)</li> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/rendering-content-default-get-servlets.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/rendering-content-default-get-servlets.html b/documentation/bundles/rendering-content-default-get-servlets.html index 06734d2..1463f66 100644 --- a/documentation/bundles/rendering-content-default-get-servlets.html +++ b/documentation/bundles/rendering-content-default-get-servlets.html @@ -78,13 +78,13 @@ Not all features of the <b>org.apache.sling.servlets.get</b> bundle are described below - this page needs more work. </div> -<h1>Default GET and HEAD servlets</h1> +<h1><a href="#default-get-and-head-servlets" name="default-get-and-head-servlets">Default GET and HEAD servlets</a></h1> <p>Sling provides a number of default GET and HEAD servlets, in the <code>org.apache.sling.servlets.get</code> bundle.</p> <p>This provides useful functionality out of the box: JSON rendering of content for example, usually does not require custom code.</p> <p>This page provides an overview of these default servlets.</p> <p>Currently, only the <code>DefaultGetServlet</code> has configuration parameters. Those are found at <code>/system/console/configMgr/org.apache.sling.servlets.get.DefaultGetServlet</code> on a standard Sling setup, and should be self-explaining. One common use is to disable some of the default renderings listed below, as they might not be useful or desired on production systems. </p> -<h1>Default renderings</h1> -<h2>Default JSON rendering</h2> +<h1><a href="#default-renderings" name="default-renderings">Default renderings</a></h1> +<h2><a href="#default-json-rendering" name="default-json-rendering">Default JSON rendering</a></h2> <p>Adding a .json extension to a request triggers the default Sling GET servlet in JSON mode, unless a more specific servlet or script is provided for the current resource.</p> <p>This servlet currently supports the following selectors:</p> <ul> @@ -93,19 +93,19 @@ page needs more work. <li>A numeric value or <code>.infinity</code> as the last selector selects the desired recursion level</li> </ul> <p>Note that the number of elements is limited by a configurable value, see the <code>DefaultGetServlet</code> configuration for more info.</p> -<h2>Default HTML rendering</h2> +<h2><a href="#default-html-rendering" name="default-html-rendering">Default HTML rendering</a></h2> <p>In a similar way, adding a <code>.html</code> extension to a request triggers the default Sling GET servlet in HTML mode. That rendering just dumps the current node values in a readable way, but it's only really useful for troubleshooting.</p> -<h2>Default text rendering</h2> +<h2><a href="#default-text-rendering" name="default-text-rendering">Default text rendering</a></h2> <p>A basic text rendering is also provided if the request has a <code>.txt</code> extension, unless more specific servlets or scripts are provided.</p> -<h2>Default XML rendering</h2> +<h2><a href="#default-xml-rendering" name="default-xml-rendering">Default XML rendering</a></h2> <p>Adding a <code>.xml</code> extension triggers the default XML rendering, once again unless a more specific script or servlet is registered for the current resource.</p> <p>That XML rendering currently uses the JCR "document view" export functionality directly, so it only supports rendering resources that are backed by JCR nodes.</p> -<h2>StreamRendererServlet</h2> +<h2><a href="#streamrendererservlet" name="streamrendererservlet">StreamRendererServlet</a></h2> <p>Whenever the request carries the extension <code>.res</code> or no extension at all, the resource's input stream is spooled to the servlet response (leveraging <code>Resource.adaptTo(InputStream.class)</code>). This servlet supports conditional requests (<a href="https://tools.ietf.org/html/rfc7232";>RFC 7232</a>) evaluating the resource's modification date from <code>Resource.getResourceMetadata().getModificationTime()</code> and range requests (<a href="https://tools.ietf.org/html/rfc7233";>RFC 7233</a>).</p> -<h2>RedirectServlet</h2> +<h2><a href="#redirectservlet" name="redirectservlet">RedirectServlet</a></h2> <p>The <code>RedirectServlet</code> handles the <code>sling:redirect</code> resource type, using the <code>sling:target</code> property of the resource to define the redirect target, and the <code>sling:status</code> property to define the HTTP status to use (default is 302).</p> <p>This is not to be confused with the <code>sling:redirect</code> property used under <code>/etc/map</code>, which is described in <a href="/documentation/the-sling-engine/mappings-for-resource-resolution.html">Mappings for Resource Resolution</a></p> -<h2>SlingInfoServlet</h2> +<h2><a href="#slinginfoservlet" name="slinginfoservlet">SlingInfoServlet</a></h2> <p>The <code>SlingInfoServlet</code> provides info on the current JCR session, for requests that map to JCR nodes.</p> <p>It is available at <code>/system/sling/info.sessionInfo</code> by default, and supports <code>.json</code> and <code>.txt</code> extensions. </p></section></div></div> <div class="footer"> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/repository-initialization.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/repository-initialization.html b/documentation/bundles/repository-initialization.html index a649cc3..30641f2 100644 --- a/documentation/bundles/repository-initialization.html +++ b/documentation/bundles/repository-initialization.html @@ -75,7 +75,7 @@ </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p>The <code>SlingRepositoryInitializer</code> mechanism allows for running code before the <code>SlingRepository</code> service is registered.</p> <p>This is useful for initialization and content migration purposes.</p> <p>Please be aware of potential clustering and coordination issues when using this mechanism, if your environment lets several Sling instances access the same content repository you'll need to implement a synchronization mechanism for such operations.</p> -<h2>SlingRepositoryInitializer</h2> +<h2><a href="#slingrepositoryinitializer" name="slingrepositoryinitializer">SlingRepositoryInitializer</a></h2> <p>The <code>SlingRepositoryInitializer</code> is a very simple service interface, available from version 2.4.0 of the <code>org.apache.sling.jcr.api</code> and <code>org.apache.sling.jcr.base</code> bundles.</p> <pre><code>public interface SlingRepositoryInitializer { public void processRepository(SlingRepository repo) throws Exception; @@ -84,7 +84,7 @@ <p>Services that implement this interface are called when setting up the JCR-based <code>SlingRepository</code> service, before registering it as an OSGi service.</p> <p>They are called in increasing order of their <code>service.ranking</code> service property, which needs to be an <code>Integer</code> as usual.</p> <p>If any of them throws an Exception, the <code>SlingRepository</code> service is not registered.</p> -<h2>The 'repoinit' Repository Initialization Language</h2> +<h2><a href="#the-repoinit-repository-initialization-language" name="the-repoinit-repository-initialization-language">The 'repoinit' Repository Initialization Language</a></h2> <p>The <code>org.apache.sling.repoinit.parser</code> implements a mini-language meant to create paths, service users and Access Control Lists in a content repository, as well as registering JCR namespaces and node types.</p> <p>The language grammar is defined (using the JavaCC compiler-compiler, which has no runtime dependencies) in the <code>RepoInitGrammar.jjt</code> file in that module, and the automated tests provide a number of <a href="https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases";>test cases</a> which demonstrate various features.</p> <p>The companion <code>org.apache.sling.jcr.repoinit</code> module implements those operations on an Oak JCR repository, using a <code>SlingRepositoryInitializer</code> registered by default with a service ranking of 100. It also provides a <code>JcrRepoInitOpsProcessor</code> service to explicitly apply the output of the repoinit parser to a JCR repository.</p> @@ -153,7 +153,7 @@ create user demoUser with password {SHA-256} dc460da4ad72c482231e28e688e01f2778a create service user the-last-one </code></pre> -<h2>Providing repoinit statements from the Sling provisioning model or other URLs</h2> +<h2><a href="#providing-repoinit-statements-from-the-sling-provisioning-model-or-other-urls" name="providing-repoinit-statements-from-the-sling-provisioning-model-or-other-urls">Providing repoinit statements from the Sling provisioning model or other URLs</a></h2> <p>All bundles required for this feature need to be active before the <code>SlingRepository</code> service starts.</p> <p>From version 1.0.2 of the <code>org.apache.sling.jcr.repoinit</code> bundle, the <code>o.a.s.jcr.repoinit.RepositoryInitializer</code> component uses an OSGi configuration as shown in this example to define where to read repoinit statements:</p> <pre><code>org.apache.sling.jcr.repoinit.impl.RepositoryInitializer @@ -162,7 +162,7 @@ create service user the-last-one <p>This example defines two <em>references</em> to URLs that supply repoinit statements. Their syntax is described below.</p> <p>By default the <code>RepositoryInitializer</code> uses the first URL shown in the above example, which points to the provisioning model that's embedded by default in the Sling Launchpad runnable jar.</p> <p>Note that previous versions of the <code>org.apache.sling.jcr.repoinit</code> bundle used different configuration parameters. From version 1.0.2 on, warnings are logged if those old parameters (_text.url,text.format,model.section.name_) are used.</p> -<h3>References to Sling Provisioning Model additional sections</h3> +<h3><a href="#references-to-sling-provisioning-model-additional-sections" name="references-to-sling-provisioning-model-additional-sections">References to Sling Provisioning Model additional sections</a></h3> <p>The <code>slingstart-maven-plugin</code>, from V1.4.2 on, allows for embedding so-called "additional sections" in the Sling provisioning model by starting their name with a colon.</p> <p>At runtime this requires the <code>org.apache.sling.provisioning.model</code> bundle, version 1.4.2 or later.</p> <p>The <code>o.a.s.jcr.repoinit</code> bundle can use this feature to execute <code>repoinit</code> statements provided by Sling provisioning models, as in this provisioning model example fragment:</p> @@ -177,7 +177,7 @@ create service user provisioningModelUser <p>Where <em>model</em> means "use the provisioning model format", <em>repoinitTwo</em> is the name of the additional section to read statements from in the provisioning model (without the leading colon) and <em>context:/resources/...</em> is the URL to use to retrieve the provisioning model.</p> <p>In this example the URL uses the <em>context</em> scheme defined by the Sling Launchpad, but any scheme can be used provided a suitable URL handler is active.</p> <p>The section name in that reference is optional and defaults to <em>repoinit</em>. If it's not specified the <code>@</code> should be omitted as well.</p> -<h3>References to URLs providing raw repoinit statements</h3> +<h3><a href="#references-to-urls-providing-raw-repoinit-statements" name="references-to-urls-providing-raw-repoinit-statements">References to URLs providing raw repoinit statements</a></h3> <p>Using a <code>RepositoryInitializer</code> reference like in this example, with the <em>raw</em> prefix, means that its content is passed as is to the repoinit parser:</p> <pre><code>raw:classpath://some-repoinit-file.txt </code></pre> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/request-analysis.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/request-analysis.html b/documentation/bundles/request-analysis.html index 73f99ce..d024885 100644 --- a/documentation/bundles/request-analysis.html +++ b/documentation/bundles/request-analysis.html @@ -74,7 +74,7 @@ Request Processing Analyzer (reqanalyzer) </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p><!-- TODO reactivate TOC once JBake moves to flexmark-java --> </p> -<h2>Introduction</h2> +<h2><a href="#introduction" name="introduction">Introduction</a></h2> <p>Sling provides a helpful functionality to track progress of requests being processed: The <a href="http://sling.apache.org/apidocs/sling6/org/apache/sling/api/request/RequestProgressTracker.html";>RequestProgressTracker</a> which is available through the <a href="http://sling.apache.org/apidocs/sling6/org/apache/sling/api/SlingHttpServletRequest.html#getRequestProgressTracker%28%29";>SlingHttpServletRequest</a>.</p> <p>This tool provides mechanims to record states of request processing and a simple mechanism to time periods of processing. By default Sling itself uses this tool to track progress through Sling like script resolution and calling scripts.</p> <p>Scripts and servlets called during Sling's request processing may themselves use the <code>RequestProgressTracker</code> to log their own processing.</p> @@ -89,7 +89,7 @@ <li>Response Status</li> </ul> <p>After that first line the complete data from the requests <code>RequestProgressTracker</code> is dumped.</p> -<h2>Web Console Integration</h2> +<h2><a href="#web-console-integration" name="web-console-integration">Web Console Integration</a></h2> <p>The Request Processing Analyzer is available through the Web Console in the <em>Sling</em> category to</p> <ul> <li>Download the <code>requesttracker.txt</code> file as a plain text or ZIP-ed file</li> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/resource-access-security.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/resource-access-security.html b/documentation/bundles/resource-access-security.html index ed8b8a2..a17a87a 100644 --- a/documentation/bundles/resource-access-security.html +++ b/documentation/bundles/resource-access-security.html @@ -73,17 +73,17 @@ <div class="breadcrumbs"><a href="/ng/">Home</a> » <a href="/ng/documentation.html">Documentation</a> » <a href="/ng/documentation/bundles.html">Bundles</a> » </div> <h1> Resource Access Security </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p>Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.</p> -<h2>Summary</h2> +<h2><a href="#summary" name="summary">Summary</a></h2> <p>The ResourceAccessSecurity service allows it to restrict access to resources. The access can be granted or denied for read, create, update and delete actions.</p> <p>The ResourceAccessSecurity defines a service API which is used in two different context: for securing resource providers which have no own access control and on the application level to further restrict the access to resources in general. </p> <p>A resource access security service is registered with the service property âcontextâ. Allowed values are âapplicationâ and âproviderâ. If the value is missing or invalid, the service will be ignored. </p> <p>In the context of resource providers, this service might be used for implementations of resource providers where the underlying persistence layer does not implement access control. The goal is to make it easy to implement a lightweight access control for such providers. For example, a JCR resource providers should not use the provider context resource access security - in a JCR context, security is fully delegated to the underlying repository, and mixing security models would be a bad idea. </p> <p>In the context of the application, this service might be used to add additional or temporary constraints across the whole resource tree. </p> -<h2>How to use ResourceAccessSecurity</h2> +<h2><a href="#how-to-use-resourceaccesssecurity" name="how-to-use-resourceaccesssecurity">How to use ResourceAccessSecurity</a></h2> <p>To use the ResourceAccessSecurity service you donât have to implement the interface ResourceAccessSecurity. Simply add the resourceaccesssecurity bundle to your sling instance. This adds an implementation of the ResourceAccessSecurity service for the provider context (âproviderâ) and also the application context (âapplicationâ).</p> <p>Furthermore the implementation of ResourceAccessSecurity defines a service provider interface named ResourceAccessGate. This is the service interface which you can implement and register to control the access to the resources.</p> <p>The ResourceAccessGate defines a service API which can be used to make some restrictions to accessing resources. Implementations of this service interface must be registered like ResourceProvider with a path (like provider.roots but with the property name âpathâ). If different ResourceAccessGate services match a path, not only the ResourceAccessGate with the longest path will be called, but all of them, that's in contrast to the ResourceProvider, but in this case more logical (and secure!). The access gates also must be registered with a context (âapplicationâ or âproviderâ), without a given context, the service will be ignored by ResourceAccessSecurity. The gates will be called in the order of the service ranking. If one of the gates grants access for a given operation access will be granted. An exception are the gates which are registered for âfinaloperationsâ. If such a gate denies resource access no further gate will be asked and access denied (except a gate w ith higher service ranking has granted access).</p> -<h3>Service properties</h3> +<h3><a href="#service-properties" name="service-properties">Service properties</a></h3> <table> <thead> <tr> @@ -110,10 +110,9 @@ </tr> </tbody> </table> -<h3>How to implement ResourceAccessGate</h3> +<h3><a href="#how-to-implement-resourceaccessgate" name="how-to-implement-resourceaccessgate">How to implement ResourceAccessGate</a></h3> <p>The implementation is straightforward. The easiest way is to extend <code>AllowingResourceAccessGate</code> which is exported by the resourceaccesssecurity bundle and does not deny any access. So if you wanât restrict access on resources for read operations you have to implement to following two methods:</p> -<pre><code>::java -@Override +<pre><code><!-- TODO syntax marker (::java) disabled -->@Override public boolean hasReadRestrictions(final ResourceResolver resourceResolver) { return true; } @@ -133,7 +132,7 @@ public GateResult canRead(final Resource resource) { </code></pre> <p>And you have to register the ResourceAccessGate with the path where you wanât to restrict access and the operation property set to âreadâ. Furthermore you have to decide if the ResourceAccessGate should operate on all resource providers (context=âapplicationâ) or only on the resourceproviders flagged with the property useResourceAccessSecurity=true (context=âproviderâ).</p> <p>Tip: We do not recommend to mix up application and provider context in the same application. This can lead to confusing configurations in the ResourceAccessGate implementations.</p> -<h3>GateResult</h3> +<h3><a href="#gateresult" name="gateresult">GateResult</a></h3> <p>GateResult does have three states:</p> <ul> <li>GateResult.GRANTED</li> @@ -141,7 +140,7 @@ public GateResult canRead(final Resource resource) { <li>GateResult.CANT_DECIDE</li> </ul> <p>The first two of them are self-explanatory. CANT_DECIDE means that the actual gate neither can grant nor deny the access. If no other gate does return GRANTED or DENIED the access to the resource will be denied for security reasons. CANT-DECIDE comes handy if you declare finaloperations (where no other gate will be called after this gate). If such a gate returns CANT_DECIDE, further gates will be called regardless of the setted finaloperations property.</p> -<h2>Actual state of ResourceAccessSecurity</h2> +<h2><a href="#actual-state-of-resourceaccesssecurity" name="actual-state-of-resourceaccesssecurity">Actual state of ResourceAccessSecurity</a></h2> <p>By now the implementation is complete for securing access on resource level for CRUD operations. It is not yet ready to allow fine granular access rights on values of a resource. So at the moment the <code>canReadValue, canUpdateValue, canDeleteValue</code> and <code>canCreateValue</code> on <code>ResourceAccessGate</code> methods are ignored.</p></section></div></div> <div class="footer"> <div class="trademarkFooter"> http://git-wip-us.apache.org/repos/asf/sling-site/blob/f542b22e/documentation/bundles/resource-editor.html ---------------------------------------------------------------------- diff --git a/documentation/bundles/resource-editor.html b/documentation/bundles/resource-editor.html index 4b8e332..47a1814 100644 --- a/documentation/bundles/resource-editor.html +++ b/documentation/bundles/resource-editor.html @@ -74,7 +74,7 @@ The Apache Sling Resource Editor </h1><div class="row"><div class="small-12 columns"><section class="wrap"><p>Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.</p> <p><img src="http://sling.apache.org/documentation/bundles/resource-editor-screenshot.png"; alt="alt text" /></p> -<h1>Features</h1> +<h1><a href="#features" name="features">Features</a></h1> <p>Currently it allows to display the node properties and edit nodes.</p> <ul> <li>Node editing includes adding, renaming and deleting nodes.</li> @@ -83,9 +83,9 @@ <li>The add node dialog provides you with the allowed node name / node type / resource type options and its combinations to prevent errors soon. Click on the info icon in the dialog to discover more.</li> <li>The nodes are bookmarkable.</li> </ul> -<h1>Status</h1> +<h1><a href="#status" name="status">Status</a></h1> <p>The features for the node tree are finished so far. Now the work on making properties editable begins.</p> -<h1>Installation</h1> +<h1><a href="#installation" name="installation">Installation</a></h1> <ol> <li>Follow the <a href="http://sling.apache.org/documentation/development/getting-and-building-sling.html";>instructions for Getting and Building Sling</a>.</li> <li>The <code>contrib/explorers/resourceeditor/README</code> file in SVN tells you how to install the Resource Editor.</li>
![http://sling.apache.org/documentation/bundles/resource-editor-screenshot.png"](http://sling.apache.org/documentation/bundles/resource-editor-screenshot.png"){kind=link}