Skip Main Navigation
Let's talk

OSGi Configuration via JCR Nodes

Everything is content - that's the CQ5 credo. It also holds for configurations of OSGi services, which can be set by content nodes. Here's a short overview of how it can be used.

OSGI Configuration

The reasons to configure OSGi services via content nodes is obvious:

 

  • Configurations are deployed with the code
  • Configurations can be transferred with content packages
  • Configurations can be managed with source control

 

Defining an OSGi configuration with content nodes is pretty simple:

You create a sling:Folder 'config' and add nodes below it of type sling:OsgiConfig. This node has to have the name of the persistence ID, usually that's the fully qualified class name of the service you want to configure, e.g. com.day.cq.wcm.core.impl.VersionManagerImpl.

Therefore, you can configure the service with an xml file in the folder /apps/yourproject/config with the name com.day.cq.wcm.core.impl.VersionManagerImpl.xml and the following content:

<?xml version="1.0" encoding="UTF-8">
<jcr:root 
xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primartyType="sling:OsgiConfig"
versionmanager.maxNumberVersions="{Long}5"
versionmanager.ivPaths="/"
versionmanager.purgePaths="[/etc/feeds,/home/users/public,/home/groups/public]"
versionmanager.createVersionOnActivation="{Boolean}true"
versionmanager.maxAgeDays="{Long}3"
versionmanager.purgingEnabled="{Boolean}true" />

You can add factory configurations (multiple settings for one configuration) by adding a unique identifier to the file name, separated by a hyphen. Setting up the MCM configuration e.g. can be done by providing a file named com.day.cq.mcm.impl.MCMConfiguration-myConfiguration.xml. This will create a binding to the configuration.

Only one open topic remains: You usually have one code base, but multiple configuration according to the various systems: An integration test author system has different configurations compared to a production publish system. The instances can be distinguished by using different runmodes, and the configurations can be runmode specific as well:

Just add the name of the runmode the set of configurations apply to the config-folder, like 'config.author' or 'config.publish'. By this you can maintain all applicable configurations in the version control, deploy the code, activate the packages - and the instance itself picks the proper settings. Pretty neat, isn't it?


Stefan Franck

Executive Director

One Netcentric’s co-founders, Stefan is an expert in shaping solutions for clients - from requirements analysis to project specification and more. Stefan sees himself as the link between business and technology and, for over ten years now, he has filled various roles as architect, project lead and lead consultant. Stefan's focus is on the Adobe Marketing Cloud and AEM, to which he is strongly connected from his days at Day Software and Adobe. He says that co-founding Netcentric was one of the best choices in his professional life. Never before been able to work with so many brilliant people.

Cookies policy

We use cookies to deliver a better experience. By using our website, you agree to use cookies in accordance with our privacy policy.

We use cookies to deliver a better experience. By using our website, you agree to use cookies in accordance with our privacy policy.