Managing OSGI bundle configurations using content-nodes in the repository

OSGi is used to control the configurations of bundles in AEM. OSGi allows easy management of bundles as the bundles can be started, stopped and installed at any time. The inter-dependencies between bundles are automatically handled.
There are majorly two ways to configure the bundles in AEM. Using,
· Adobe CQ Web Console
· Content nodes in Repository
But, I would suggest never using the CQ web console to configure the bundles in AEM. Rather, always use [make it a habit] to use content-nodes [sling:osgiconfig] in the repository to configure the bundles in AEM.
Now the question would arise like, why one should not use CQ web console to configure bundles?
Below are some of my observations, while accessing the values of the bundle parameters configured via the CQ web console.
· Every value configured in the CQ web console gets saved in the repository itself.
· If you configure bundles using the CQ web console, the configurations are saved under app/sling/config or apps/system/config.
· We cannot control the location where this node will be saved.
· The node will always be saved under config [sling:Folder].
· As it is saved under the config folder and not under config.author/config.publish folder, the configurations will load for all run modes. It will not be specific for an author or publish mode.
· Actual configuration data gets stored inside jcr:content node as a binary file.
· New configuration node will be created under config[sling:folder] as <pid>.config [nt:file]
· The actual configuration data is stored in jcr:content node’s properties. A jcr:data property will store configurations in binary format.
Example:
Day CQ Mail Service bundle configurations are changed from CQ web console https://localhost:4502/system/console/configMgr



In CRXDE, configurations are reflected under apps/system/config folder [after refresh]. Actual configuration is stored under jcr:data property as binary data file.






Keeping all the above points in mind, when you try to access the configuration parameters programmatically, you have to
· Search for specific configuration using the <pid> of the bundle in apps/system/config and apps/sling/config, as you are not sure about its location.
· Then write a code to access and read the binary data file from jcr: data property of the jcr:content node under config.
· Once accessed, manipulate and adjust the desired parameter in binary file programmatically
· And then again write back the values to jcr: data of the node.
This seems to be a very complex task to achieve.


Majority of the above mentioned challenges can be overcome by configuring the bundles using content-nodes (sling:osgiConfig) in the repository.
Where,
· Every value configured in CQ web console can be saved in the repository under folder specified by the developer
· You can save the configuration nodes under your project folder (i.e. apps/<myproject>/ config)
· Now we have full control of the location where this node will be saved.
· The configurations can be Run mode-specific.
· As we have the flexibility to save under config.author/config.publish folder, the configurations can be run mode specific now. Configurations under config.author will load for author instance and configurations under config.publish will load for the author instance.
· Actual configuration data gets stored as properties of [sling:osgiconfig] node.
· Configuration node needs to be created under a folder of type [sling:folder] as node of type [sling:osgiconfig].
· The actual configuration data is stored in properties under [sling:osgiconfig] which can be accessed easily
Example:
1. Three configurations are added.
· config:- apply for all instances.
· config.author:- apply for the author's instance.
· config.publish:- apply for publish instance.



2. Configurations added as properties for config.author instance



3. Once we save the new configurations in CRXDE. We need to refresh the CQ web console to see the changes.



If the developer wants to manage the configurations [content-nodes (sling:osgiConfig) in the repository] programmatically, it will be an easy task for a developer to get access to properties of a node using Sling API or JCR API. Developers can easily access, manipulate and save the properties of a configuration done using content-nodes.