In order to follow this how-to you'll need the following on your computer:
A Composite NodeStore is a repository composed of two or more nodestores. The nodestores work together to provide a single logical repository. Like a UNIX file system, each nodestore acts similar to file system mount points. For example, you can mount the
/content node as read-write and the
/libs nodes as read-only.
The Composite NodeStore can be used to improve the stability of your site. In general, you can think of a Sling site as consisting of two parts: your content (which changes often) and your application (which changes periodically). Unless there's a scheduled application release, there's very little reason to allow a running Sling instance to be changed from a code/application perspective.
It provides a great way to ensure that application changes are not allowed without an official release, but still allow day-to-day editorial content changes. Some of the benefits of using the Composite NodeStore and separating your content and application concerns are:
Let's take a quick look at what will happen behind the scenes as we work through this tutorial.
/libsJCR nodes. These nodes will later become read-only.
Build the Kickstarter and install it into your local Maven repository.
$ git clone https://github.com/apache/sling-org-apache-sling-kickstart.git $ cd sling-org-apache-sling-kickstart $ mvn clean install
Start Sling for the first time using the seed creation script.
This script uses the Kickstarter to start Sling with two Feature Models:
feature-sling12-two-headed.json- Our main Feature Model. Sling Feature Model without a NodeStore
feature-two-headed-seed.json- Additional Feature Model. Feature Model with a single NodeStore
When you see the line below, Sling has been fully initialized and should be safely stopped by entering
ESAPI: SUCCESSFULLY LOADED validation.properties via the CLASSPATH from '/ (root)'...
Now, let's start Sling a second time using the Composite NodeStore.
1. Let's start by making a post request and add a JCR property to the
$ curl -s -v -u admin:admin -FtestProperty='I can write to the content node' \ 'http://localhost:8080/content/slingshot' > /dev/null ... < HTTP/1.1 200 OK ...
Since this is a read-write repository path, you should receive an HTTP 200 OK response and be able to write to a property called
testProperty with the value
I can write to the content node on the
2. Now, let's try the same test, but let's attempt to write to a read-only node.
$ curl -s -v -u admin:admin -FtestProperty='I cannot write to the apps node' \ 'http://localhost:8080/apps/slingshot' > /dev/null ... < HTTP/1.1 500 Server Error ...
You should now receive an HTTP 500 error response. So, even as the admin user you can't write to the
/apps section of the repository.
If you stick with us, we'll show you how to convert an existing Provisioning Model to a Feature Model..