http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/nosql-resource-providers.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/nosql-resource-providers.md b/content/documentation/bundles/nosql-resource-providers.md index 8e765f8..0d0f07a 100644 --- a/content/documentation/bundles/nosql-resource-providers.md +++ b/content/documentation/bundles/nosql-resource-providers.md @@ -1,7 +1,10 @@ -title=NoSQL Resource Providers (org.apache.sling.nosql) -type=page +title=TODO title for nosql-resource-providers.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: NoSQL Resource Providers (org.apache.sling.nosql) [TOC] @@ -31,11 +34,11 @@ Tested with MongoDB Server 3.0.6 and MongoDB Java Driver 3.1.1. Configuration example: -org.apache.sling.nosql.mongodb.resourceprovider.MongoDBNoSqlResourceProviderFactory.factory.config-default -provider.roots=["/"] -connectionString="localhost:27017" -database="sling" -collection="resources" + org.apache.sling.nosql.mongodb.resourceprovider.MongoDBNoSqlResourceProviderFactory.factory.config-default + provider.roots=["/"] + connectionString="localhost:27017" + database="sling" + collection="resources" 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. @@ -52,14 +55,14 @@ Tested with Couchbase Server 4.0.0 and Couchbase Java SDK 2.2.4. Please note: Co Configuration example: -org.apache.sling.nosql.couchbase.resourceprovider.CouchbaseNoSqlResourceProviderFactory.factory.config-default -provider.roots=["/"] + org.apache.sling.nosql.couchbase.resourceprovider.CouchbaseNoSqlResourceProviderFactory.factory.config-default + provider.roots=["/"] -org.apache.sling.nosql.couchbase.client.CouchbaseClient.factory.config-default -clientId="sling-resourceprovider-couchbase" -couchbaseHosts="localhost:8091" -bucketName="sling" -enabled=B"true" + org.apache.sling.nosql.couchbase.client.CouchbaseClient.factory.config-default + clientId="sling-resourceprovider-couchbase" + couchbaseHosts="localhost:8091" + bucketName="sling" + enabled=B"true" 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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/org-apache-sling-junit-bundles.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/org-apache-sling-junit-bundles.md b/content/documentation/bundles/org-apache-sling-junit-bundles.md index 8eae937..b2c6524 100644 --- a/content/documentation/bundles/org-apache-sling-junit-bundles.md +++ b/content/documentation/bundles/org-apache-sling-junit-bundles.md @@ -1,16 +1,19 @@ -title=JUnit server-side testing support bundles -type=page +title=TODO title for org-apache-sling-junit-bundles.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: JUnit server-side testing support bundles -This is an overview of the Sling bundles that provide support for server-side JUnit tests. +This is an overview of the Sling bundles that provide support for server-side JUnit tests. -The Maven modules below [`testing/samples`](https://svn.apache.org/repos/asf/sling/trunk/testing/samples) -provide different examples including HTTP-based and server-side teleported tests in a +The Maven modules below [`testing/samples`](https://svn.apache.org/repos/asf/sling/trunk/testing/samples) +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. ## org.apache.sling.junit.core: server-side JUnit tests support -This bundle provides a `JUnitServlet` that runs JUnit tests found in bundles. +This bundle provides a `JUnitServlet` that runs JUnit tests found in bundles. <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. @@ -24,12 +27,12 @@ To make tests available to that servlet, the bundle that contains them must poin with a `Sling-Test-Regexp` bundle header that defines a regular expression that matches the test class names, like for example: -Sling-Test-Regexp=com.example.*ServerSideTest + Sling-Test-Regexp=com.example.*ServerSideTest ### The TeleporterRule The `TeleporterRule` supplied by this bundle (since V1.0.12) makes it easy to write such tests, as it takes care of -all the mechanics of +all the mechanics of 1. creating the test bundle including all necessary classes for execution 1. adding the `Sling-Test-Regexp` header to the bundles manifest @@ -40,29 +43,29 @@ all the mechanics of Most of these steps are done on the client-side by the org.apache.sling.junit.teleporter module (see below). Using this rule the server-side tests can be mixed with other tests in the source code if that's convenient, it just -requires the `junit.core` and `junit.teleporter` modules described on this page to create such tests. +requires the `junit.core` and `junit.teleporter` modules described on this page to create such tests. Here's a basic example of a server-side test that accesses OSGi services: -public class BasicTeleporterTest { - -@Rule -public final TeleporterRule teleporter = TeleporterRule.forClass(getClass(), "Launchpad"); - -@Test -public void testConfigAdmin() throws IOException { -final String pid = "TEST_" + getClass().getName() + UUID.randomUUID(); - -final ConfigurationAdmin ca = teleporter.getService(ConfigurationAdmin.class); -assertNotNull("Teleporter should provide a ConfigurationAdmin", ca); - -final Configuration cfg = ca.getConfiguration(pid); -assertNotNull("Expecting to get a Configuration", cfg); -assertEquals("Expecting the correct pid", pid, cfg.getPid()); -} -} - -That's all there is to it, the `TeleporterRule` takes care of the rest. + public class BasicTeleporterTest { + + @Rule + public final TeleporterRule teleporter = TeleporterRule.forClass(getClass(), "Launchpad"); + + @Test + public void testConfigAdmin() throws IOException { + final String pid = "TEST_" + getClass().getName() + UUID.randomUUID(); + + final ConfigurationAdmin ca = teleporter.getService(ConfigurationAdmin.class); + assertNotNull("Teleporter should provide a ConfigurationAdmin", ca); + + final Configuration cfg = ca.getConfiguration(pid); + assertNotNull("Expecting to get a Configuration", cfg); + assertEquals("Expecting the correct pid", pid, cfg.getPid()); + } + } + +That's all there is to it, the `TeleporterRule` takes care of the rest. The test bundle being build and deployed through this rule usually happens quickly as the temporary bundle is very small. Both the client-side and server-side parts of the test can be debugged easily @@ -71,29 +74,29 @@ with the appropriate IDE settings. The `Teleporter.getService` method takes an optional OSGi LDAP filter for service selection, like for example: -final StringTransformer t = teleporter.getService(StringTransformer.class, "(mode=uppercase)"); + final StringTransformer t = teleporter.getService(StringTransformer.class, "(mode=uppercase)"); The method waits for the service to be available or until the timeout elapsed ([SLING-6031](https://issues.apache.org/jira/browse/SLING-6031)). And starting with version 1.0.4 of the `org.apache.sling.junit.teleporter` bundle, you can specify resources to embed in the test bundle, as in this example: -@Rule -public final TeleporterRule teleporter = -TeleporterRule.forClass(getClass(), "Launchpad") -.withResources("/foo/", "/some/other/resource.txt"); + @Rule + public final TeleporterRule teleporter = + TeleporterRule.forClass(getClass(), "Launchpad") + .withResources("/foo/", "/some/other/resource.txt"); which will embed all resources found under `/foo` as well as the `resource.txt` in the test bundle, making them available to the server-side tests. This teleporter mechanism is used in our integration tests, search for `TeleporterRule` in there -for examples or look at the +for examples or look at the [`integrationtest.teleporter`]( https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/teleporter) -package. +package. -As I write this the teleporter mechanism is quite new, I suspect there might be some weird interactions +As I write this the teleporter mechanism is quite new, I suspect there might be some weird interactions between things like `@AfterClass`, custom test runners and this mechanism but it works well to a growing -number of tests in our `launchpad/integration-tests` module. Moving to JUnit `Rules` as much as possible, +number of tests in our `launchpad/integration-tests` module. Moving to JUnit `Rules` as much as possible, and combining them using JUnit's `RuleChain`, should help work around such limitations if they arise. ### More details on the JUnitServlet @@ -102,14 +105,14 @@ bundle that contains tests and a `Sling-Test-Regexp` bundle header that points t described above. Or use the `TeleporterRule` and set a breakpoint in the tests execution, when the test bundle in installed and listed by the test servlet. -To list the available tests, open `/system/sling/junit/` in your browser. The servlet shows available tests and allows +To list the available tests, open `/system/sling/junit/` in your browser. The servlet shows available tests and allows you to execute them via a POST request. -Adding a path allows you to select a specific subset of tests, as in +Adding a path allows you to select a specific subset of tests, as in `/system/sling/junit/org.apache.sling.junit.remote.html` - -The JUnitServlet provides various output formats, including in particular JSON, see -`/system/sling/junit/.json` for example. + + The JUnitServlet provides various output formats, including in particular JSON, see + `/system/sling/junit/.json` for example. ## org.apache.sling.junit.teleporter: client-side TeleporterRule support This module provides the `ClientSideTeleporter` which the `TeleporterRule` uses to package the server-side tests @@ -121,8 +124,8 @@ This module is not a bundle, as it's used on the client only, as a dependency wh A `TeleporterRule.Customizer` is used to setup the `ClientSideTeleporter`. That customizer is instantiated dynamically based on a String passed to the `TeleporterRule.forClass` method as 2nd parameter. As an example from our `launchpad/integration-tests` module, this call -TeleporterRule.forClass(getClass(), "Launchpad:author"); - + TeleporterRule.forClass(getClass(), "Launchpad:author"); + causes the `TeleporterRule` to use the `org.apache.sling.junit.teleporter.customizers.LaunchpadCustomizer` class to setup the `ClientSideTeleporter`, and passes the "author" string to it as an option. Although our current `LaunchpadCustomizer` does not use this options string, it is meant to select a specific server (of family of servers) to run the tests on. @@ -131,9 +134,9 @@ The options string can also use a full class name instead of the `Launchpad` sho of that string that follows the first colon is passed to the customizer as is. Using Strings for customization reduces the coupling with the `junit.core` bundle, as it does not need to know those -classes which are used only on the client side when running tests. +classes which are used only on the client side when running tests. -If `TeleporterRule.forClass(getClass())` is used (the method without an additional 2nd parameter) the default customizer is used ([SLING-5677](https://issues.apache.org/jira/browse/SLING-5677), since version 1.0.8). +If `TeleporterRule.forClass(getClass())` is used (the method without an additional 2nd parameter) the default customizer is used ([SLING-5677](https://issues.apache.org/jira/browse/SLING-5677), since version 1.0.8). The following customizers are currently used in Sling @@ -171,7 +174,7 @@ Those should give you an overview on what can be done with a customizer and deci This bundle allows JUnit tests to run as [Sling Health Checks](/documentation/bundles/sling-health-check-tool.html), which can be useful when defining smoke tests for example, allowing them to be used both at build time and run time. -See the `JUnitHealthCheck` class for details. +See the `JUnitHealthCheck` class for details. ## org.apache.sling.junit.scriptable: scriptable server-side tests This bundle allows Sling scripts to be executed from the `JUnitServlet` as JUnit tests, as follows: @@ -182,32 +185,32 @@ This bundle allows Sling scripts to be executed from the `JUnitServlet` as JUnit Here's a minimal example that sets up and executes a scriptable test: -$ curl -u admin:admin -Fjcr:primaryNodeType=sling:Folder -Fsling:resourceType=foo -Fjcr:mixinTypes=sling:Test http://localhost:8080/apps/foo -... -$ echo TEST_PASSED > /tmp/test.txt.esp ; curl -u admin:admin -T/tmp/test.txt.esp http://localhost:8080/apps/foo/test.txt.esp - + $ curl -u admin:admin -Fjcr:primaryNodeType=sling:Folder -Fsling:resourceType=foo -Fjcr:mixinTypes=sling:Test http://localhost:8080/apps/foo + ... + $ echo TEST_PASSED > /tmp/test.txt.esp ; curl -u admin:admin -T/tmp/test.txt.esp http://localhost:8080/apps/foo/test.txt.esp + At this point, foo.test.txt is what the scriptable test framework will request, and that outputs just TEST_PASSED: - -$ curl -u admin:admin http://localhost:8080/apps/foo.test.txt -TEST_PASSED - + + $ curl -u admin:admin http://localhost:8080/apps/foo.test.txt + TEST_PASSED + And a POST to the JUnit servlet returns information on the test's execution: -curl -u admin:admin -XPOST http://localhost:8080/system/sling/junit/org.apache.sling.junit.scriptable.ScriptableTestsProvider.json -[{ -"INFO_TYPE": "test", -"description": "verifyContent[0](org.apache.sling.junit.scriptable.TestAllPaths)", -"test_metadata": { -"test_execution_time_msec": 2 -} -} -] + curl -u admin:admin -XPOST http://localhost:8080/system/sling/junit/org.apache.sling.junit.scriptable.ScriptableTestsProvider.json + [{ + "INFO_TYPE": "test", + "description": "verifyContent[0](org.apache.sling.junit.scriptable.TestAllPaths)", + "test_metadata": { + "test_execution_time_msec": 2 + } + } + ] 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. +same request again. ## org.apache.sling.junit.remote: obsolete The `org.apache.sling.junit.remote` bundle provides utilities to run server-side JUnit tests, but using the newer `TeleporterRule` described above is much simpler. As a result, this bundle -should only be needed for existing tests that were written using its mechanisms. +should only be needed for existing tests that were written using its mechanisms. http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/osgi-installer.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/osgi-installer.md b/content/documentation/bundles/osgi-installer.md index 26a06ab..275db45 100644 --- a/content/documentation/bundles/osgi-installer.md +++ b/content/documentation/bundles/osgi-installer.md @@ -1,7 +1,10 @@ -title=OSGi Installer -type=page +title=TODO title for osgi-installer.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: OSGi Installer # Overview @@ -18,7 +21,7 @@ As the OSGi installer itself is not performing the actual install, update or rem It's possible to add own providers, transformers and installer factories to support custom scenarios. ## API -The installer API is defined by the `org.apache.sling.installer.api` package +The installer API is defined by the `org.apache.sling.installer.api` package of the [org.apache.sling.installer.core](http://svn.apache.org/repos/asf/sling/trunk/installer/core/) module. The main interface is the `OsgiInstaller` with which installable resources can be registered. http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.md b/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.md index 5b9bc45..d5a95a7 100644 --- a/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.md +++ b/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.md @@ -1,7 +1,10 @@ -title=Output Rewriting Pipelines (org.apache.sling.rewriter) -type=page +title=TODO title for output-rewriting-pipelines-org-apache-sling-rewriter.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Output Rewriting Pipelines (org.apache.sling.rewriter) 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. @@ -17,7 +20,7 @@ The first component in the pipeline generating the initial SAX events is called Between the generator and the serializer so called transformers can be placed in a chain. A transformer receives SAX events from the previous component in the pipeline and sends SAX events to the next component in the pipeline. A transformer can remove events, change events, add events or just pass on the events. -Sling contains a default pipeline which is executed for all HTML responses: it starts with an HTML generator, parsing the HTML output and sending events into the pipeline. An HTML serializer collects all events and serializes the output. +Sling contains a default pipeline which is executed for all HTML responses: it starts with an HTML generator, parsing the HTML output and sending events into the pipeline. An HTML serializer collects all events and serializes the output. The pipelines can be configured in the repository as a child node of */apps/APPNAME/config/rewriter* (or */libs/APPNAME/config/rewriter*). (In fact the configured search paths of the resource resolver are observed.) Each node can have the following properties: @@ -35,7 +38,7 @@ The pipelines can be configured in the repository as a child node of */apps/APPN 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. -If a component needs a configuration, the configuration is stored in a child node which name is *{componentType}-{name}*, e.g. to configure the HTML generator (named *html-generator*), the node should have the name *generator-html-generator*. In the case that the pipeline contains the same transformer several times, the configuration child node should have the formant *{componentType}-{index}* 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 *transformer-1* (for the first xslt), *transformer-html-cleaner*, *transformer-3* (for the second xslt), and *transformer-link-checker*. +If a component needs a configuration, the configuration is stored in a child node which name is *\{componentType\}\-\{name\}*, e.g. to configure the HTML generator (named *html\-generator*), the node should have the name *generator-html-generator*. In the case that the pipeline contains the same transformer several times, the configuration child node should have the formant *\{componentType\}-\{index\}* 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 *transformer-1* (for the first xslt), *transformer-html-cleaner*, *transformer-3* (for the second xslt), and *transformer-link-checker*. ### Default Pipeline @@ -47,10 +50,10 @@ As the HTML generated by Sling is not required to be valid XHTML, the HTML parse 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: -::java -@scr.component metatype="no" -@scr.service interface="TransformerFactory" -@scr.property value="pipeline.type" value="validator" + ::java + @scr.component metatype="no" + @scr.service interface="TransformerFactory" + @scr.property value="pipeline.type" value="validator" 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 *pipeline.type* property. The pipeline configuration in the repository just references this unique name (like validator). @@ -59,11 +62,11 @@ With the possibilities from above, it is possible to define new pipelines and ad 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: -::java -@scr.component metatype="no" -@scr.service interface="TransformerFactory" -@scr.property name="pipeline.mode" value="global" -@scr.property name="service.ranking" value="RANKING" type="Integer" + ::java + @scr.component metatype="no" + @scr.service interface="TransformerFactory" + @scr.property name="pipeline.mode" value="global" + @scr.property name="service.ranking" value="RANKING" type="Integer" *RANKING* 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. @@ -79,10 +82,10 @@ The *getWriter* method should return a writer where the output is written to. Wh Like the pipeline components a processor is generated by a factory which has to be registered as a service factory, like this: -::java -@scr.component metatype="no" -@scr.service interface="ProcessorFactory" -@scr.property value="pipeline.type" value="uniqueName" + ::java + @scr.component metatype="no" + @scr.service interface="ProcessorFactory" + @scr.property value="pipeline.type" value="uniqueName" ## Configuring a Processor http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/rendering-content-default-get-servlets.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/rendering-content-default-get-servlets.md b/content/documentation/bundles/rendering-content-default-get-servlets.md index ebed222..e7b896e 100644 --- a/content/documentation/bundles/rendering-content-default-get-servlets.md +++ b/content/documentation/bundles/rendering-content-default-get-servlets.md @@ -1,7 +1,10 @@ -title=Rendering Content - Default GET Servlets -type=page +title=TODO title for rendering-content-default-get-servlets.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Rendering Content - Default GET Servlets [TOC] @@ -22,19 +25,19 @@ This page provides an overview of these default servlets. Currently, only the `DefaultGetServlet` has configuration parameters. Those are found at `/system/console/configMgr/org.apache.sling.servlets.get.DefaultGetServlet` 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. +as they might not be useful or desired on production systems. # Default renderings ## Default JSON rendering -Adding a .json extension to a request triggers the default Sling GET servlet in JSON mode, unless a +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. This servlet currently supports the following selectors: -* `.tidy` causes the JSON output to be formatted -* `.harray` causes child nodes to be output as arrays instead of objects, to preserve their order (requires `org.apache.sling.servlets.get` V2.1.10) -* A numeric value or `.infinity` as the last selector selects the desired recursion level + * `.tidy` causes the JSON output to be formatted + * `.harray` causes child nodes to be output as arrays instead of objects, to preserve their order (requires `org.apache.sling.servlets.get` V2.1.10) + * A numeric value or `.infinity` as the last selector selects the desired recursion level Note that the number of elements is limited by a configurable value, see the `DefaultGetServlet` configuration for more info. @@ -66,11 +69,11 @@ Whenever the request carries the extension `.res` or no extension at all, the re The `RedirectServlet` handles the `sling:redirect` resource type, using the `sling:target` property of the resource to define the redirect target, and the `sling:status` property to define the HTTP status to use (default is 302). -This is not to be confused with the `sling:redirect` property used under `/etc/map`, which is described in +This is not to be confused with the `sling:redirect` property used under `/etc/map`, which is described in [Mappings for Resource Resolution](/documentation/the-sling-engine/mappings-for-resource-resolution.html) ## SlingInfoServlet The `SlingInfoServlet` provides info on the current JCR session, for requests that map to JCR nodes. -It is available at `/system/sling/info.sessionInfo` by default, and supports `.json` and `.txt` extensions. +It is available at `/system/sling/info.sessionInfo` by default, and supports `.json` and `.txt` extensions. http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/repository-initialization.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/repository-initialization.md b/content/documentation/bundles/repository-initialization.md index f501e0c..68c627a 100644 --- a/content/documentation/bundles/repository-initialization.md +++ b/content/documentation/bundles/repository-initialization.md @@ -1,5 +1,7 @@ -title= +title=Repository Initializers and Repository Initialization Language +date=2013-08-25 type=page +tags=repoinit,repository status=published ~~~~~~ @@ -13,18 +15,18 @@ the same content repository you'll need to implement a synchronization mechanism ## SlingRepositoryInitializer The `SlingRepositoryInitializer` is a very simple service interface, available from version 2.4.0 of the `org.apache.sling.jcr.api` and `org.apache.sling.jcr.base` bundles. -public interface SlingRepositoryInitializer { -public void processRepository(SlingRepository repo) throws Exception; -} - + public interface SlingRepositoryInitializer { + public void processRepository(SlingRepository repo) throws Exception; + } + Services that implement this interface are called when setting up the JCR-based `SlingRepository` service, before registering it as an OSGi service. They are called in increasing order of their `service.ranking` service property, which needs to be an `Integer` as usual. If any of them throws an Exception, the `SlingRepository` service is not registered. - + ## The 'repoinit' Repository Initialization Language -The `org.apache.sling.repoinit.parser` implements a mini-language meant to create paths, service users and Access Control Lists in a content repository, as +The `org.apache.sling.repoinit.parser` 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. The language grammar is defined (using the JavaCC compiler-compiler, which has no runtime dependencies) in the `RepoInitGrammar.jjt` file in that module, and the automated tests provide a number of [test cases](https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases) which demonstrate various features. @@ -33,83 +35,83 @@ The companion `org.apache.sling.jcr.repoinit` module implements those operations registered by default with a service ranking of 100. It also provides a `JcrRepoInitOpsProcessor` service to explicitly apply the output of the repoinit parser to a JCR repository. -Here's a current example from the test cases mentioned above, that uses all language features as of version 1.0.2 of the parser module. +Here's a current example from the test cases mentioned above, that uses all language features as of version 1.0.2 of the parser module. The language is self-explaining but please refer to the actual test cases for details that are guaranteed to be up to date, assuming the tests pass. -create service user user1, u-ser_2 -set ACL on /libs,/apps -allow jcr:read for user1,u-ser_2 - -deny jcr:write for u-ser_2 -deny jcr:lockManagement for user1 -remove jcr:understand,some:other for u3 -end - -create service user bob_the_service - -set ACL on /tmp -allow some:otherPrivilege for bob_the_service -end - -# Nodetypes inside the path apply to just that path element -create path /content/example.com(sling:Folder) - -# A nodetype in front is used as the default for all path elements -create path (nt:unstructured) /var - -set ACL for alice, bob,fred -# remove is currently not supported by the jcr.repoinit module -remove * on / -allow jcr:read on /content,/var -deny jcr:write on /content/example.com -deny jcr:all on / nodetypes example:Page -end - -set ACL for restrictions_examples -deny jcr:modifyProperties on /apps, /content nodetypes sling:Folder, nt:unstructured restriction(rep:itemNames,prop1,prop2) -allow jcr:addChildNodes on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) -allow jcr:modifyProperties on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) restriction(rep:itemNames,prop1,prop2) -allow jcr:addChildNodes on /apps,/content restriction(rep:glob,/cat/*,*/cat,*cat/*) -end - -# register namespace requires -# o.a.s.repoinit.parser 1.0.4 -# and o.a.s.jcr.repoinit 1.0.2 -register namespace ( NSprefix ) uri:someURI/v1.42 - -# register nodetypes in CND format -# (same bundle requirements as register namespaces) -# -# The optional << markers are used when embedding -# this in a Sling provisioning model, to avoid syntax errors -# -# The CND instructions are passed as is to the JCR -# modules, so the full CND syntax is supported. -# -register nodetypes -<<=== -<< <slingevent='http://sling.apache.org/jcr/event/1.0'> -<< -<< [slingevent:Event] > nt:unstructured, nt:hierarchyNode -<< - slingevent:topic (string) -<< - slingevent:properties (binary) -===>> - -create user demoUser with password {SHA-256} dc460da4ad72c482231e28e688e01f2778a88ce31a08826899d54ef7183998b5 - -create service user the-last-one + create service user user1, u-ser_2 + set ACL on /libs,/apps + allow jcr:read for user1,u-ser_2 + + deny jcr:write for u-ser_2 + deny jcr:lockManagement for user1 + remove jcr:understand,some:other for u3 + end + + create service user bob_the_service + + set ACL on /tmp + allow some:otherPrivilege for bob_the_service + end + + # Nodetypes inside the path apply to just that path element + create path /content/example.com(sling:Folder) + + # A nodetype in front is used as the default for all path elements + create path (nt:unstructured) /var + + set ACL for alice, bob,fred + # remove is currently not supported by the jcr.repoinit module + remove * on / + allow jcr:read on /content,/var + deny jcr:write on /content/example.com + deny jcr:all on / nodetypes example:Page + end + + set ACL for restrictions_examples + deny jcr:modifyProperties on /apps, /content nodetypes sling:Folder, nt:unstructured restriction(rep:itemNames,prop1,prop2) + allow jcr:addChildNodes on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) + allow jcr:modifyProperties on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) restriction(rep:itemNames,prop1,prop2) + allow jcr:addChildNodes on /apps,/content restriction(rep:glob,/cat/*,*/cat,*cat/*) + end + + # register namespace requires + # o.a.s.repoinit.parser 1.0.4 + # and o.a.s.jcr.repoinit 1.0.2 + register namespace ( NSprefix ) uri:someURI/v1.42 + + # register nodetypes in CND format + # (same bundle requirements as register namespaces) + # + # The optional << markers are used when embedding + # this in a Sling provisioning model, to avoid syntax errors + # + # The CND instructions are passed as is to the JCR + # modules, so the full CND syntax is supported. + # + register nodetypes + <<=== + << <slingevent='http://sling.apache.org/jcr/event/1.0'> + << + << [slingevent:Event] > nt:unstructured, nt:hierarchyNode + << - slingevent:topic (string) + << - slingevent:properties (binary) + ===>> + + create user demoUser with password {SHA-256} dc460da4ad72c482231e28e688e01f2778a88ce31a08826899d54ef7183998b5 + + create service user the-last-one ## Providing repoinit statements from the Sling provisioning model or other URLs All bundles required for this feature need to be active before the `SlingRepository` service starts. -From version 1.0.2 of the `org.apache.sling.jcr.repoinit` bundle, the `o.a.s.jcr.repoinit.RepositoryInitializer` component uses an OSGi +From version 1.0.2 of the `org.apache.sling.jcr.repoinit` bundle, the `o.a.s.jcr.repoinit.RepositoryInitializer` component uses an OSGi configuration as shown in this example to define where to read repoinit statements: -org.apache.sling.jcr.repoinit.impl.RepositoryInitializer -references=["model:context:/resources/provisioning/model.txt","model@repoinitTwo:context:/resources/provisioning/model.txt"] - + org.apache.sling.jcr.repoinit.impl.RepositoryInitializer + references=["model:context:/resources/provisioning/model.txt","model@repoinitTwo:context:/resources/provisioning/model.txt"] + This example defines two _references_ to URLs that supply repoinit statements. Their syntax is described below. By default the `RepositoryInitializer` 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. @@ -122,30 +124,30 @@ their name with a colon. At runtime this requires the `org.apache.sling.provisioning.model` bundle, version 1.4.2 or later. -The `o.a.s.jcr.repoinit` bundle can use this feature to execute `repoinit` statements provided by Sling provisioning models, as in this +The `o.a.s.jcr.repoinit` bundle can use this feature to execute `repoinit` statements provided by Sling provisioning models, as in this provisioning model example fragment: -[:repoinit] -create path /repoinit/provisioningModelTest - -create service user provisioningModelUser + [:repoinit] + create path /repoinit/provisioningModelTest + create service user provisioningModelUser + To read repoinit statements from such an additional provisioning model section, the `RepositoryInitializer` configuration shown above uses references like -model@repoinitTwo:context:/resources/provisioning/model.txt - -Where _model_ means "use the provisioning model format", _repoinitTwo_ is the name of the additional section to read statements from in the provisioning + model@repoinitTwo:context:/resources/provisioning/model.txt + +Where _model_ means "use the provisioning model format", _repoinitTwo_ is the name of the additional section to read statements from in the provisioning model (without the leading colon) and _context:/resources/..._ is the URL to use to retrieve the provisioning model. In this example the URL uses the _context_ scheme defined by the Sling Launchpad, but any scheme can be used provided a suitable URL handler is active. The section name in that reference is optional and defaults to _repoinit_. If it's not specified the `@` should be omitted as well. - + ### References to URLs providing raw repoinit statements Using a `RepositoryInitializer` reference like in this example, with the _raw_ prefix, means that its content is passed as is to the repoinit parser: -raw:classpath://some-repoinit-file.txt - + raw:classpath://some-repoinit-file.txt + Which points to a `classpath:` URL to provide the raw repoinit statements in this example, but again any valid URL scheme can be used. - + http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/request-analysis.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/request-analysis.md b/content/documentation/bundles/request-analysis.md index cde35eb..dd0de13 100644 --- a/content/documentation/bundles/request-analysis.md +++ b/content/documentation/bundles/request-analysis.md @@ -1,7 +1,10 @@ -title=Request Processing Analyzer (reqanalyzer) -type=page +title=TODO title for request-analysis.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Request Processing Analyzer (reqanalyzer) [TOC] @@ -44,7 +47,7 @@ that is on the same host as the Sling instance is running. To analyze the `requesttracker.txt` file the *Request Processing Analyzer* module can also be used as a standalone Java application. Just start the module using the `java` command: -$ java -jar org.apache.sling.reqanalyzer-0.0.1-SNAPSHOT.jar requesttracker.txt + $ java -jar org.apache.sling.reqanalyzer-0.0.1-SNAPSHOT.jar requesttracker.txt The command supports two command line arguments: http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/resource-access-security.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/resource-access-security.md b/content/documentation/bundles/resource-access-security.md index 7486899..fb5581b 100644 --- a/content/documentation/bundles/resource-access-security.md +++ b/content/documentation/bundles/resource-access-security.md @@ -1,34 +1,37 @@ -title=Resource Access Security -type=page +title=TODO title for resource-access-security.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Resource Access Security 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. + 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. ## Summary The ResourceAccessSecurity service allows it to restrict access to resources. The access can be granted or denied for read, create, update and delete actions. -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. +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. -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. +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. -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. +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. -In the context of the application, this service might be used to add additional or temporary constraints across the whole resource tree. +In the context of the application, this service might be used to add additional or temporary constraints across the whole resource tree. ## How to use ResourceAccessSecurity 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â). @@ -40,34 +43,34 @@ The ResourceAccessGate defines a service API which can be used to make some rest ### Service properties Property name | description ------------------ | ----------------------- -Path | regexp to define on which paths the service should be called (default .*) -operations | set of operations on which the service should be called ("read,create,update,delete,execute", default all of them) -finaloperations | set of operations on which the service answer is final and no further service should be called (default none of them), except the GateResult is GateResult.CANT_DECIDE +----------------- | ----------------------- +Path | regexp to define on which paths the service should be called (default .*) +operations | set of operations on which the service should be called ("read,create,update,delete,execute", default all of them) +finaloperations | set of operations on which the service answer is final and no further service should be called (default none of them), except the GateResult is GateResult.CANT_DECIDE context | âproviderâ or âapplicationâ. The resource access gate can either have the context âproviderâ, in this case the gate is only applied to resource providers requesting the security checks. Or the context can be âapplicationâ. In this case the access gate is invoked for the whole resource tree. This is indicated by the required service property âcontextâ. If the property is missing or invalid, the service is ignored. ### How to implement ResourceAccessGate The implementation is straightforward. The easiest way is to extend ` AllowingResourceAccessGate ` 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: -::java -@Override -public boolean hasReadRestrictions(final ResourceResolver resourceResolver) { -return true; -} - -@Override -public GateResult canRead(final Resource resource) { -GateResult returnValue = GateResult.CANT_DECIDE; -if( whatever-condition ) { -returnValue = GateResult.GRANTED; -} -else { -returnValue = GateResult.DENIED; -} - -return returnValue; -} - + ::java + @Override + public boolean hasReadRestrictions(final ResourceResolver resourceResolver) { + return true; + } + + @Override + public GateResult canRead(final Resource resource) { + GateResult returnValue = GateResult.CANT_DECIDE; + if( whatever-condition ) { + returnValue = GateResult.GRANTED; + } + else { + returnValue = GateResult.DENIED; + } + + return returnValue; + } + 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â). 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. @@ -75,9 +78,9 @@ Tip: We do not recommend to mix up application and provider context in the same ### GateResult GateResult does have three states: -- GateResult.GRANTED -- GateResult.DENIED -- GateResult.CANT_DECIDE + - GateResult.GRANTED + - GateResult.DENIED + - GateResult.CANT_DECIDE 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. http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/resource-editor.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/resource-editor.md b/content/documentation/bundles/resource-editor.md index 2c1d155..476270b 100644 --- a/content/documentation/bundles/resource-editor.md +++ b/content/documentation/bundles/resource-editor.md @@ -1,23 +1,26 @@ -title=The Apache Sling Resource Editor -type=page +title=TODO title for resource-editor.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: The Apache Sling Resource Editor 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. + 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. ![alt text][1] @@ -25,7 +28,7 @@ Features ======== Currently it allows to display the node properties and edit nodes. -* Node editing includes adding, renaming and deleting nodes. +* Node editing includes adding, renaming and deleting nodes. * Multi selection of nodes, Keyboard controls for navigation and shortcuts are provided. Click on the info icon in the tree to get detailed information. * The node names are HTML and URL encoded. * 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. @@ -42,5 +45,5 @@ Installation 1. Open `http://localhost:8080/reseditor/.html` in your browser. 1. Enjoy! -[1]: http://sling.apache.org/documentation/bundles/resource-editor-screenshot.png -[2]: http://sling.apache.org/documentation/development/getting-and-building-sling.html + [1]: http://sling.apache.org/documentation/bundles/resource-editor-screenshot.png + [2]: http://sling.apache.org/documentation/development/getting-and-building-sling.html http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/resource-merger.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/resource-merger.md b/content/documentation/bundles/resource-merger.md index 0d4c805..2878807 100644 --- a/content/documentation/bundles/resource-merger.md +++ b/content/documentation/bundles/resource-merger.md @@ -1,7 +1,10 @@ -title=Resource Merger (org.apache.sling.resourcemerger) -type=page +title=TODO title for resource-merger.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Resource Merger (org.apache.sling.resourcemerger) [TOC] @@ -15,16 +18,16 @@ The Resource Merger bundle provides two resource provider factories Those providers give access to virtual resources which provide a merged view on multiple other resources. -Each `MergedResourcePicker` service implementation in the system provides one unique mount point/root path (usually starting with `/mnt`) exposing a view on merged resources from at least two different locations. +Each `MergedResourcePicker` service implementation in the system provides one unique mount point/root path (usually starting with `/mnt`) exposing a view on merged resources from at least two different locations. -The exact merging mechanism depends on the resource picker implementation (see below). The order of the merging is important as the overlying resource may overwrite properties/child resources from the underlying resource (but not vice-versa). +The exact merging mechanism depends on the resource picker implementation (see below). The order of the merging is important as the overlying resource may overwrite properties/child resources from the underlying resource (but not vice-versa). It is possible to * remove existing resource/properties from the underlying resources, * modify existing properties/child resources of the underlying resources and * add new properties/child resources -You may use any of the merge properties described below to influence the merging behaviour. All those special properties are not exposed below the mount point. +You may use any of the merge properties described below to influence the merging behaviour. All those special properties are not exposed below the mount point. The `CRUDMergingResourceProvider` not only gives read-access to the merged resources but even allows to write. This provider always writes inside the topmost resource path (being returned as last item by the resource picker). Currently both resource pickers shipped with the Sling Resource Merger bundle do not allow to write though. Further details can be found in the description of [SLING-3909](https://issues.apache.org/jira/browse/SLING-3909). @@ -45,18 +48,18 @@ First the ones from the base resource, then the ones from the overlaying resourc In case the same child is defined in more than one resource, its position is taken from the highest overlaying resource (since version 1.3.2, see also [SLING-4915](https://issues.apache.org/jira/browse/SLING-4915)). For example: - -base/ -+--child1 -+--child2 -+--child3 - -overlay/ -+--child4 -+--child2 -+--child3 - -resulting order: child1, child4, child2, child3 + + base/ + +--child1 + +--child2 + +--child3 + + overlay/ + +--child4 + +--child2 + +--child3 + + resulting order: child1, child4, child2, child3 You can overwrite that behaviour by leveraging the `sling:orderBefore` property. @@ -64,43 +67,43 @@ You can overwrite that behaviour by leveraging the `sling:orderBefore` property. ## Merging Resource Picker (Overlay approach) -Description | Merged Resource Path | Merging Order | Read-Only | Related Ticket + Description | Merged Resource Path | Merging Order | Read-Only | Related Ticket ------------ | -------------------- | ------------- | --------- | --------------- -Merging based on the resource resolver's search path | `/mnt/overlay/<relative resource path>` | Last resource resolver search path first (Order = Descending search paths). | `true` | [SLING-2986](http://issues.apache.org/jira/browse/SLING-2986) +Merging based on the resource resolver's search path | `/mnt/overlay/<relative resource path>` | Last resource resolver search path first (Order = Descending search paths). | `true` | [SLING-2986](http://issues.apache.org/jira/browse/SLING-2986) This picker is thought for globally overlaying content by placing the diff-resource in "/apps" without actually touching anything in "/libs" (since this is only thought for Sling itself). This should be used whenever some deviation of content is desired which is initially shipped with Sling. The client (i.e. the code using the merged resource) does not have to know if there is an overlay in place. - + ### Example -/libs/sling/example (nt:folder) -+-- sling:resourceType = "some/resource/type" -+-- child1 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child1" -+-- child2 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child2" -+-- child3 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child3" - - -/apps/sling/example (sling:Folder) -+-- property1 = "property added in apps" -+-- child1 (nt:folder) -| +-- sling:hideResource = true -+-- child2 (nt:folder) -| +-- property1 = "property from /apps/sling/example/child2" -+-- child3 (nt:folder) -| +-- property2 = "property from /apps/sling/example/child3" - - -/mnt/overlay/sling/example (sling:Folder) -+-- sling:resourceType = "some/resource/type" -+-- property1 = "property added in apps" -+-- child2 (nt:folder) -| +-- property1 = "property from /apps/sling/example/child2" -+-- child3 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child3" -| +-- property2 = "property from /apps/sling/example/child3" + /libs/sling/example (nt:folder) + +-- sling:resourceType = "some/resource/type" + +-- child1 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child1" + +-- child2 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child2" + +-- child3 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child3" + + + /apps/sling/example (sling:Folder) + +-- property1 = "property added in apps" + +-- child1 (nt:folder) + | +-- sling:hideResource = true + +-- child2 (nt:folder) + | +-- property1 = "property from /apps/sling/example/child2" + +-- child3 (nt:folder) + | +-- property2 = "property from /apps/sling/example/child3" + + + /mnt/overlay/sling/example (sling:Folder) + +-- sling:resourceType = "some/resource/type" + +-- property1 = "property added in apps" + +-- child2 (nt:folder) + | +-- property1 = "property from /apps/sling/example/child2" + +-- child3 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child3" + | +-- property2 = "property from /apps/sling/example/child3" @@ -114,33 +117,33 @@ This picker is thought for extending content of another already existing resourc ### Example -/apps/sling/base (nt:folder) -+-- child1 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child1" -+-- child2 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child2" -+-- child3 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child3" - - -/apps/sling/example (sling:Folder) -+-- sling:resourceSuperType = "/apps/sling/base" -+-- property1 = "property added in /apps/sling/example" -+-- child1 (nt:folder) -| +-- sling:hideResource = true -+-- child2 (nt:folder) -| +-- property1 = "property from /apps/sling/example/child2" -+-- child3 (nt:folder) -| +-- property2 = "property from /apps/sling/example/child3" - - -/mnt/override/apps/sling/example (sling:Folder) -+-- sling:resourceSuperType = "/apps/sling/base" -+-- property1 = "property added in /apps/sling/example" -+-- child2 (nt:folder) -| +-- property1 = "property from /apps/sling/example/child2" -+-- child3 (nt:folder) -| +-- property1 = "property from /libs/sling/example/child3" -| +-- property2 = "property from /apps/sling/example/child3" + /apps/sling/base (nt:folder) + +-- child1 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child1" + +-- child2 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child2" + +-- child3 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child3" + + + /apps/sling/example (sling:Folder) + +-- sling:resourceSuperType = "/apps/sling/base" + +-- property1 = "property added in /apps/sling/example" + +-- child1 (nt:folder) + | +-- sling:hideResource = true + +-- child2 (nt:folder) + | +-- property1 = "property from /apps/sling/example/child2" + +-- child3 (nt:folder) + | +-- property2 = "property from /apps/sling/example/child3" + + + /mnt/override/apps/sling/example (sling:Folder) + +-- sling:resourceSuperType = "/apps/sling/base" + +-- property1 = "property added in /apps/sling/example" + +-- child2 (nt:folder) + | +-- property1 = "property from /apps/sling/example/child2" + +-- child3 (nt:folder) + | +-- property1 = "property from /libs/sling/example/child3" + | +-- property2 = "property from /apps/sling/example/child3" http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/scheduler-service-commons-scheduler.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/scheduler-service-commons-scheduler.md b/content/documentation/bundles/scheduler-service-commons-scheduler.md index 4755f05..bee6d02 100644 --- a/content/documentation/bundles/scheduler-service-commons-scheduler.md +++ b/content/documentation/bundles/scheduler-service-commons-scheduler.md @@ -1,7 +1,10 @@ -title=Scheduler Service (commons scheduler) -type=page +title=TODO title for scheduler-service-commons-scheduler.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Scheduler Service (commons scheduler) The scheduler is a service for scheduling other services/jobs (it uses the open source Quartz library). The scheduler can be used in two ways, by registering the job through the scheduler API and by leveraging the whiteboard pattern that is supported by the scheduler. In most cases the whiteboard pattern is preferred @@ -9,64 +12,64 @@ The scheduler is a service for scheduling other services/jobs (it uses the open The notion of Job used in this context is a different one than the one used for <a href="/documentation/bundles/apache-sling-eventing-and-job-handling.html">Sling Jobs</a>. The main difference is that a scheduler's job is not persisted. </div> -## Examples of jobs that are scheduled by leveraging the whiteboard pattern +## Examples of jobs that are scheduled by leveraging the whiteboard pattern The following examples show you how to define and schedule a job by leveraging the whiteboard pattern. -### Scheduling with a cron expression +### Scheduling with a cron expression The following job is executed every minute by setting *scheduler.expression* to the cron expression *"0 * * * * ?"*: -package sling.docu.examples; - -import org.slf4j.Logger; -import org.slf4j.LoggerFactory; -import org.apache.felix.scr.annotations.Component; -import org.apache.felix.scr.annotations.Service; -import org.apache.felix.scr.annotations.Property; - -@Component -@Service(value = Runnable.class) -@Property( name = "scheduler.expression", value = "0 * * * * ?") -public class ScheduledCronJob implements Runnable { + package sling.docu.examples; + + import org.slf4j.Logger; + import org.slf4j.LoggerFactory; + import org.apache.felix.scr.annotations.Component; + import org.apache.felix.scr.annotations.Service; + import org.apache.felix.scr.annotations.Property; -/** Default log. */ -protected final Logger log = LoggerFactory.getLogger(this.getClass()); + @Component + @Service(value = Runnable.class) + @Property( name = "scheduler.expression", value = "0 * * * * ?") + public class ScheduledCronJob implements Runnable { + + /** Default log. */ + protected final Logger log = LoggerFactory.getLogger(this.getClass()); + + public void run() { + log.info("Executing a cron job (job#1) through the whiteboard pattern"); + } + // + } -public void run() { -log.info("Executing a cron job (job#1) through the whiteboard pattern"); -} -// -} - -### Scheduling at periodic times +### Scheduling at periodic times The following job is executed every ten seconds by setting *scheduler.period* to *10*: -package sling.docu.examples; - -import org.slf4j.Logger; -import org.slf4j.LoggerFactory; -import org.apache.felix.scr.annotations.Component; -import org.apache.felix.scr.annotations.Service; -import org.apache.felix.scr.annotations.Property; - -@Component -@Service(value = Runnable.class) -@Property( name = "scheduler.period", longValue = 10) -public class ScheduledPeriodicJob implements Runnable { - -/** Default log. */ -protected final Logger log = LoggerFactory.getLogger(this.getClass()); - -public void run() { -log.info("Executing a perodic job (job#2) through the whiteboard pattern"); -} -// -} + package sling.docu.examples; + + import org.slf4j.Logger; + import org.slf4j.LoggerFactory; + import org.apache.felix.scr.annotations.Component; + import org.apache.felix.scr.annotations.Service; + import org.apache.felix.scr.annotations.Property; + + @Component + @Service(value = Runnable.class) + @Property( name = "scheduler.period", longValue = 10) + public class ScheduledPeriodicJob implements Runnable { + + /** Default log. */ + protected final Logger log = LoggerFactory.getLogger(this.getClass()); + + public void run() { + log.info("Executing a perodic job (job#2) through the whiteboard pattern"); + } + // + } ### Preventing concurrent execution @@ -74,17 +77,17 @@ log.info("Executing a perodic job (job#2) through the whiteboard pattern"); By default, jobs can be concurrently executed. To prevent this, set the *scheduler.concurrent* property to *false*: -@Property(name="scheduler.concurrent", boolValue=false) + @Property(name="scheduler.concurrent", boolValue=false) ### Scheduling the job just once in a cluster If the same code/same services is executed on multiple nodes within a cluster, the same job might be scheduled on each instance. If this is not desired, the job can either be bound to the leader of the topology or a single instance (which one this is, is not further defined): - -@Property(name="scheduler.runOn", value="LEADER"); + + @Property(name="scheduler.runOn", value="LEADER"); or -@Property(name="scheduler.runOn", value="SINGLE"); + @Property(name="scheduler.runOn", value="SINGLE"); Since in contrast to [Sling Jobs](/documentation/bundles/apache-sling-eventing-and-job-handling.html) the scheduler queue is only held in memory, there will be no distribution of jobs. So if job '1' was scheduled on instance 'a' with the option to run on the leader only, but the leader is instance 'b', which hasn't the job in the queue, the job will never be executed by any instance! @@ -101,11 +104,11 @@ The following examples show you how to define and schedule a job that is registe The following code sample defines a *job* object that writes a message in the logs: -final Runnable job = new Runnable() { -public void run() { -log.info("Executing the job"); -} -}; + final Runnable job = new Runnable() { + public void run() { + log.info("Executing the job"); + } + }; ### Scheduling with a cron expression @@ -113,20 +116,20 @@ log.info("Executing the job"); To execute the job as defined above at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday, you can use the *addJob()* method with the following parameters: -String schedulingExpression = "0 15 10 ? * MON-FRI"; -this.scheduler.addJob("myJob", job, null, schedulingExpression, true); + String schedulingExpression = "0 15 10 ? * MON-FRI"; + this.scheduler.addJob("myJob", job, null, schedulingExpression, true); Refer to http://www.docjar.com/docs/api/org/quartz/CronTrigger.html -to define more scheduling expressions. + to define more scheduling expressions. ### Scheduling at periodic times To execute the job as defined above every 3 minutes (180 seconds), you can use the *addPeriodicJob()* method with the following parameters: -long period = 3*60; //the period is expressed in seconds -this.scheduler.addPeriodicJob("myJob", job, null, period, true); + long period = 3*60; //the period is expressed in seconds + this.scheduler.addPeriodicJob("myJob", job, null, period, true); ### Scheduling at a given time @@ -134,10 +137,10 @@ this.scheduler.addPeriodicJob("myJob", job, null, period, true); To execute the job as defined above at a specific date (on January 10th 2020), you can use the *fireJobAt()* method with the following parameters: -SimpleDateFormat formatter = new SimpleDateFormat("yyyy/MM/dd"); -String date = "2020/01/10"; -java.util.Date fireDate = formatter.parse(date); -this.scheduler.fireJobAt("myJob", job, null, fireDate); + SimpleDateFormat formatter = new SimpleDateFormat("yyyy/MM/dd"); + String date = "2020/01/10"; + java.util.Date fireDate = formatter.parse(date); + this.scheduler.fireJobAt("myJob", job, null, fireDate); @@ -146,90 +149,90 @@ this.scheduler.fireJobAt("myJob", job, null, fireDate); The code implementing a service that simultaneously executes the job based on 3 different kinds of scheduling can look as follows: -package sling.docu.examples; - -import java.io.Serializable; -import java.util.Date; -import java.util.HashMap; -import java.util.Map; - -import org.apache.sling.commons.scheduler.Scheduler; -import org.osgi.service.component.ComponentContext; -import org.slf4j.Logger; -import org.slf4j.LoggerFactory; -import org.apache.felix.scr.annotations.Component; -import org.apache.felix.scr.annotations.Reference; - -/** -* This service executes scheduled jobs -* -*/ -@Component -public class HelloWorldScheduledService { - -/** Default log. */ -protected final Logger log = LoggerFactory.getLogger(this.getClass()); - -/** The scheduler for rescheduling jobs. */ -@Reference -private Scheduler scheduler; - - -protected void activate(ComponentContext componentContext) throws Exception { -//case 1: with addJob() method: executes the job every minute -String schedulingExpression = "0 * * * * ?"; -String jobName1 = "case1"; -Map<String, Serializable> config1 = new HashMap<String, Serializable>(); -boolean canRunConcurrently = true; -final Runnable job1 = new Runnable() { -public void run() { -log.info("Executing job1"); -} -}; -try { -this.scheduler.addJob(jobName1, job1, config1, schedulingExpression, canRunConcurrently); -} catch (Exception e) { -job1.run(); -} - -//case 2: with addPeriodicJob(): executes the job every 3 minutes -String jobName2 = "case2"; -long period = 180; -Map<String, Serializable> config2 = new HashMap<String, Serializable>(); -final Runnable job2 = new Runnable() { -public void run() { -log.info("Executing job2"); -} -}; -try { -this.scheduler.addPeriodicJob(jobName2, job2, config2, period, canRunConcurrently); -} catch (Exception e) { -job2.run(); -} - -//case 3: with fireJobAt(): executes the job at a specific date (date of deployment + delay of 30 seconds) -String jobName3 = "case3"; -final long delay = 30*1000; -final Date fireDate = new Date(); -fireDate.setTime(System.currentTimeMillis() + delay); -Map<String, Serializable> config3 = new HashMap<String, Serializable>(); -final Runnable job3 = new Runnable() { -public void run() { -log.info("Executing job3 at date: {} with a delay of: {} seconds", fireDate, delay/1000); -} -}; -try { -this.scheduler.fireJobAt(jobName3, job3, config3, fireDate); -} catch (Exception e) { -job3.run(); -} -} - -protected void deactivate(ComponentContext componentContext) { -log.info("Deactivated, goodbye!"); -} - -} + package sling.docu.examples; + + import java.io.Serializable; + import java.util.Date; + import java.util.HashMap; + import java.util.Map; + + import org.apache.sling.commons.scheduler.Scheduler; + import org.osgi.service.component.ComponentContext; + import org.slf4j.Logger; + import org.slf4j.LoggerFactory; + import org.apache.felix.scr.annotations.Component; + import org.apache.felix.scr.annotations.Reference; + + /** + * This service executes scheduled jobs + * + */ + @Component + public class HelloWorldScheduledService { + + /** Default log. */ + protected final Logger log = LoggerFactory.getLogger(this.getClass()); + + /** The scheduler for rescheduling jobs. */ + @Reference + private Scheduler scheduler; + + + protected void activate(ComponentContext componentContext) throws Exception { + //case 1: with addJob() method: executes the job every minute + String schedulingExpression = "0 * * * * ?"; + String jobName1 = "case1"; + Map<String, Serializable> config1 = new HashMap<String, Serializable>(); + boolean canRunConcurrently = true; + final Runnable job1 = new Runnable() { + public void run() { + log.info("Executing job1"); + } + }; + try { + this.scheduler.addJob(jobName1, job1, config1, schedulingExpression, canRunConcurrently); + } catch (Exception e) { + job1.run(); + } + + //case 2: with addPeriodicJob(): executes the job every 3 minutes + String jobName2 = "case2"; + long period = 180; + Map<String, Serializable> config2 = new HashMap<String, Serializable>(); + final Runnable job2 = new Runnable() { + public void run() { + log.info("Executing job2"); + } + }; + try { + this.scheduler.addPeriodicJob(jobName2, job2, config2, period, canRunConcurrently); + } catch (Exception e) { + job2.run(); + } + + //case 3: with fireJobAt(): executes the job at a specific date (date of deployment + delay of 30 seconds) + String jobName3 = "case3"; + final long delay = 30*1000; + final Date fireDate = new Date(); + fireDate.setTime(System.currentTimeMillis() + delay); + Map<String, Serializable> config3 = new HashMap<String, Serializable>(); + final Runnable job3 = new Runnable() { + public void run() { + log.info("Executing job3 at date: {} with a delay of: {} seconds", fireDate, delay/1000); + } + }; + try { + this.scheduler.fireJobAt(jobName3, job3, config3, fireDate); + } catch (Exception e) { + job3.run(); + } + } + + protected void deactivate(ComponentContext componentContext) { + log.info("Deactivated, goodbye!"); + } + + } http://git-wip-us.apache.org/repos/asf/sling-site/blob/53c84cf9/content/documentation/bundles/scripting.md ---------------------------------------------------------------------- diff --git a/content/documentation/bundles/scripting.md b/content/documentation/bundles/scripting.md index 44530c0..8f44d33 100644 --- a/content/documentation/bundles/scripting.md +++ b/content/documentation/bundles/scripting.md @@ -1,7 +1,10 @@ -title=Sling Scripting -type=page +title=TODO title for scripting.md +date=1900-01-01 +type=post +tags=blog status=published ~~~~~~ +Title: Sling Scripting [TOC] @@ -23,4 +26,4 @@ Sling Scripting allows the easy development and usage of different scripting (ak * Velocity * * XProc * -* in contrib +\* in contrib
