Context Aware configuration in AEM

Configurations are the vital part of any project. The decision on how to handle and maintain this can be considered as the most crucial part in the development activity. In AEM we can handle configurations in different ways. A simple OSGI configuration can be considered for most number of use cases where environment specific values are not required. It is not an ideal way to go for OSGI configuration when we have third party integrations that expose different urls for different environments. This will hamper the process of regular CI/CD activity as we need to manually change the configurations after each deployment in different environments. We can choose run mode configuration in this use case. Just like that I want to talk about another method of handling configuration, the context aware configuration.

First let me write about the implementation and at the later stage I’ll help you with some use cases.

Just like the name this configuration can be applied based on the context. Let’s say if you want to apply some set of values under the path /content/abc and an entirely different set of values under the path /content/xyz, all you have to do is to keep two set of configurations by following the same hierarchy under the conf folder. In a traditional OSGI config approach we’ll keep all the configuration values under one place and programmatically we’ll check the path url and corresponding property value will be taken. Here also we keep the configurations in the node type sling:Osgiconfig but separately, based on context path. The sling:configRef jcr property with value of configuration path under the content page node will be used to pick the property values.

In the screenshot above you can see that I’ve created three configurations with the context path cntxtaware/content/en/sling:configs, cntxtaware/content/en/ca-level1/sling:configs and cntxtaware/content/fr/sling:configs. These property values will be available once it is called using the jcr property sling:configRef from the content node.

The context aware configuration follow a child hierarchy, say for example all the pages under cntxtaware/fr will be getting the same property values that is configured under the context path ‘cntxtaware/content/fr/sling:configs’  even if the child pages do not have any sling:configRef property provided the page cntxtaware/fr is referred to the config path. The page ‘cntxtaware/content/en’ will take the property values from the config path ‘cntxtaware/content/en/ sling:configs’. The page ‘cntxtaware/content/en/ca-level1’ is configured with the config path ‘cntxtaware/content/en/ca-level1/sling:configs’. So the page ‘cntxtaware/content/en/ca-level1/ca-level2’ also inherit the parent configuration, that is ‘cntxtaware/content/en/ca-level1/sling:configs’.

In Java side this can be consumed just like a OSGI configuration.

ConfigurationBuilder api needs to be used to get the value. This can be applied on OSGI service, servlets or anywhere. In my example I am using a sling model to get the property value. So that I can easily add the component in my page to verify.

The results are blow.

I have a bad habit on creating separate repositories for different functionalities. One day I’ll combine all my work together in a single project until then you can access this project from the below github path.

https://github.com/thatsmeadarsh/context-aware-config.git

This project is created using the archetype 15, so you’ll see the same template structure without test modules.

So where can we use this?

There are many use cases you can think about. When you have some third party applications to be integrated and they’ll provide you different token values for different regions or some logical implementation to disassociate certain hierarchy of pages with a different menu/navigation etc you can leverage the capability of context aware configuration.