OSGi Configuration Management – AEM

 

AEM comes with the OSGi bundle configuration console to manage the configurations of a bundle. Yes! It’s easy and perfect to handle the configuration properties of a bundle which are inbuilt with AEM. But I see some drawbacks with this approach when we have the similar configurations for our custom bundles as listed below

  1. Storage of the configuration properties

By default all the configurations will be stored directly under config folder (/apps/sling/config or /apps/system/config). Here we will not have any control on customizing where to store and also we cannot control on the availability of these configurations for a specific run modes. Click here to see how to create multiple run modes in crxde

  1. Accessibility of the configurations

When these configurations are saved, it will store in JCR with type nt:file . This will have a node jcr:content and all the values of these configuration will be stored in a property called jcr:data within this node which will be in a binary format. Due to this, readability of the configuration properties will be a challenge using the development mode (CRXde). Also it will be a challenge if we have to add/update any of the property through the code

OSGI Configuration as Binary
OSGI Configuration as Binary

To overcome these issues, I would prefer creating a configuration node manually and use the properties of a node for each of the configuration settings. This helps me to address the above issues of choosing the folder within the project  and also to control the run mode in which these configurations needs to be executed. This can be done by following the below steps

  1. Creating a runtime folder 

Create folders /apps/myproject/config.author and /apps/myproject/config.publish. Make sure the config.author and config.publish folders are of type sling:Folder

Run Mode Folders
Run Mode folders
  1. Creating a configuration node 

Create a node of type sling:OsgiConfig under the runtime folder you wish to configure. The name of the node should be the same name as the Persistent Identity (PID) of the configuration in the OSGi Console.

PID in OSGi console
PID in OSGi console

 

Configuration Node
Configuration Node
  1. Add properties 

Add ‘n’ number of properties required for each configuration with configuration description as the property name and the value of the configuration as the values of the properties.

Configuration properties
Configuration properties

when we refresh the same configuration in OSGi console, all the properties and its value would reflect there aswell. This helps in changing the values in future using CRXde and through the code aswell without decoding the binary data.

3 thoughts on “OSGi Configuration Management – AEM

  1. FWIW, I wholeheartedly agree with this assessment. While the writeback feature from the web console is convenient from time to time, I would try to use sling:OsgiConfig nodes wherever possible.

     

Leave a Reply

Your email address will not be published. Required fields are marked *