Home » Documentation » Bundles

JCR Installer Provider

The JCR installer provider scans the JCR repository for artifacts and provides them to the OSGI installer.

Configuration and Scanning

The JCR installer provider can be configured with weighted paths which are scanned. By default, the installer scans in /apps and /libs where artifacts found in /apps get a higher priority. The installer does a deep scan and uses a regular expression to detect folders containing artifacts to be installed. By default, artifacts from within a folder named install are provided to the OSGi installer.

If such an install folder contains a binary artifact (e.g. a bundle) this is provided to the OSGi installer. In addition a node of type sling:OsgiConfig is provided as a configuration to the installer.

The jcr installer provider does not check or scan the artifacts itself, the detection and installation is deferred to the OSGi installer.

Runmode Support

The JCR installer supports run modes for installing artifacts. By default folders named install are checked for artifacts. If Apache Sling is started with one (or more run modes), all folders named install.[RUNMODE] are scanned as well. To be precise, the folder name can be followed by any number of run modes separated by comma. For example, if started with run modes dev, a1, and public, folders like install.dev, install.a1, install.public are searched as well as install.dev.a1, or install.a1.dev.

Artifacts from folders with a run mode get a higher priority. For example by default, an install folder underneath /libs gets the priority 50. For each run mode in the folder name, this priority is increased by 1, so install.dev has 51 and install.a1.dev is 52.

Start Level Support

If the parent folder of a bundle has a name which is a number, this is used as the start level (when installing the bundle for the first time, compare with SLING-2011). So e.g. a bundle in the path /libs/sling/install/15/somebundle.jar is having the start level 15.


Here's a quick walkthrough of the JCR installer functionality.


Start the Sling launchpad/app and make sure that the following bundles are present and started: RunMode service OSGi installer service (org.apache.sling.installer.core) * JCR installer provider (org.apache.sling.installer.provider.jcr)

To watch the logs produced by these modules, you can filter sling/logs/error.log using egrep 'jcrinstall|osgi.installer'.

Install and remove a bundle

We'll use the Knopflerfish Desktop bundle for this example, it is convenient as it displays a graphical user interface when started.

We use curl to create content, to make it easy to reproduce the example by copying and pasting the curl commands. Any other way to create content in the repository will work, of course.

By default, JCRInstall picks up bundles found in folders named install under /libs and /apps, so we start by creating such a folder:

curl -X MKCOL  http://admin:admin@localhost:8888/apps/jcrtest
curl -X MKCOL  http://admin:admin@localhost:8888/apps/jcrtest/install

And we copy the bundle to install in that folder (a backslash in command lines means continued on next line):

curl -T desktop_awt_all-2.0.0.jar \

That's it. After 2-3 seconds, the bundle should be picked up by JCRInstall, installed and started. If this works you'll see a small Knopflerfish Desktop window on your desktop, and Sling's OSGi console can of course be used to check the details.

Removing the bundle from the repository will cause it to be uninstalled, so:

curl -X DELETE \

Should cause the Knopflerfish Desktop window to disappear as the bundle is uninstalled.

Install, modify and remove a configuration

JCRInstall installs OSGi configurations from nodes having the sling:OsgiConfig node type, found in folders named install under the installation roots (/apps and /libs).

Let's try this feature by creating a configuration with two properties:

curl \
  -F "jcr:primaryType=sling:OsgiConfig" \
  -F foo=bar -F works=yes \

And verify the contents of our config node:

curl \

Which should display something like

"jcr:created":"Wed Aug 26 2009 17:06:40GMT+0200",

At this point, JCRInstall should have picked up our new config and installed it. The logs would confirm that, but we can also use the OSGi console's config status page (http://localhost:8888/system/console/config) to check it. That page should now contain:


Indicating that the configuration has been installed.

Let's try modifying the configuration parameters:

curl \
  -F works=updated -F even=more \

And check the changes in the console page:


We can now delete the configuration node:

curl -X DELETE \

And verify that the corresponding configuration is gone in the console page (after 1-2 seconds, like for all other JCRInstall operations).

TODO: A node named like o.a.s.foo.bar-a uses o.a.s.foo.bar as its factory PID creating a configuration with an automatically generated PID. The value of a is stored as an alias property in the configuration to correlate the configuration object with the repository node - demonstrate that.

Automated Tests

The following modules contain lots of automated tests (under src/test, as usual):

Many of these tests are fairly readable, and can be used to find out in more detail how these modules work.

Project Info

Rev. 1665466 by kwin on Tue, 10 Mar 2015 11:00:56 +0000
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.