How does an AEM OSGi Config work?

Overview
In this post, I would like to explain to the readers about how does an OSGi (i.e Open service gateway interface) Config work? I would like to clarify some doubts in this post.

What is AEM OSGi Config?
AEM OSGi config is a mechanism to maintain configurations which are bound to change & varies based on different scenarios. Like loading the same config file with QA, Stage & Prod with different entries. OSGi configs are available within the OSGi runtime environment so those can be used by any other service at any time with help of the OSGi service registry model.

How to use OSGi Configs?
To use OSGi Config in your OSGi based application like AEM (i.e Adobe experience manager). Just have an XML File & bind configuration entries (i.e XML file) with Java service or component registered in the OSGi framework. Here is the AEM example. See a simple XML file & relative OSGi service.

# OSGi XML File naming convention

com.osgiConfig.example.OsgiConfigExample.xml

#XML File Content in source code.

<?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:primaryType="sling:OsgiConfig"

    servicePath="https://example.com/api/geolocation"/>

package com.osgiConfig.example;

@Service

@Component

public class OsgiConfigExample implements SlingSafeMethodsServlet {

   @Property(label = "service path",value = "exmple.com")

   private static final String SERVICE_PATH = "servicePath";

   public void doGet(SlingHttpServletRequest req, SlingHttpServletResponse res) 

   {// your code goes here ...}

}

The following order of precedence is used:

• Repository nodes under /apps/*/config….either with type sling:OsgiConfig or property files.
• Repository nodes with type sling:OsgiConfig under /libs/*/config…. (out-of-the-box definitions).
• Any .config files from <cq-installation-dir>/crx-quickstart/launchpad/config/…. on the local file system.

Is the Naming convention of XML File necessary?
Yes. Your xml file must follow name convention and that is package name & service class name where the properties annotations are.

Do you really need XML File in our source code?
Yes. OSGi config files must be maintained & put in run mode config folders in your source code. Like config, config.author, config.author.QA etc. If those are not maintained that way, you need to open OSGi config from the OSGi admin console & change the config. It becomes more difficult when you have to do the same in the production environment.

Is it really need to have property annotation at the class level?
This question is important because most of us think that if we have OSGi config XML in run mode & it matches the service package name & class then the required configuration would be available to use. However, that is not the case. Property annotation gets resolved when an OSGi service/component becomes active in the OSGi runtime environment. And OSGi service resolves these properties at the service level. So if you do not have these properties at the service level then Service or component do not load OSGI config’s from your run mode.

Final Thought
Here I tried to put some of the questions & their answers. But still, there could be some questions which are not listed here. You can post in comment & I will get back to you.