AEM OSGi Config Resolution Order

Overview
In this post, we will talk about the simple concept what is OSGi (i.e open service gateway interface) resolution order & what does this order is different when AEM starts & when something we change from OSGi console.
OSGI Config Resolution Order: at Startup vs Runtime

AEM Apache Felix based OSGi runtime environment(aka system console) loads the configurations in two different ways and makes them available to the application.

The same OSGi Apache Felix framework loads configuration runtime different. The following order of precedence applies:

1. If you have modified any config directly from system console (i.e AEM OSGi admin console) then AEM creates another .config file and this file gets precedence over your XML file, apps, or libs.
2. If you have made changes in the config file under apps and the same config has not been modified from system console then apps modified config would take the precedence over libs and will available to the application immediately.
3. If you have modified any config under libs & it is not overridden at the apps level & it is not modified from system console then modified config will take the precedence.

Config Resolution Order with multiple run modes:
For run mode specific configurations, multiple run modes can be combined. For example, you can create configuration folders in the following style:

/apps/*/config.<runmode1>.<runmode2>/

Configurations in such folders will be applied if all run modes match a run mode defined at startup. For example, if an instance was started with the run modes author,dev,emea, configuration nodes in /apps/*/config.emea, /apps/*/config.author.dev/ and /apps/*/config.author.emea.dev/ will be applied, while configuration nodes in /apps/*/config.author.asean/ and /config/author.dev.emea.noldap/ will not be applied.

If multiple configurations for the same PID are applicable, the configuration with the highest number of matching run modes is applied.

For example, if an instance was started with the run modes author,dev,emea, and both /apps/*/config.author/ and /apps/*/config.emea.author/ define a configuration for
com.day.cq.wcm.core.impl.VersionManagerImpl, the configuration in /apps/*/config.emea.author/ will be applied.

This rule’s granularity is at a PID level. You cannot define some properties for the same PID in /apps/*/config.author/ and more specific ones in /apps/*/config.emea.author/ for the same PID.
The configuration with the highest number of matching run modes will be effective for the entire PID.