OSGi configuration loading and inheritance issues across AEM Cloud environments
Adobe Experience Manager as a Cloud Service (AEMaaCS) encounters OSGi configuration issues when values appear missing, duplicated, or inconsistent across environments. This occurs due to strict runmode-based resolution, Git-driven deployment, and pod-level configuration loading. To resolve the issue, correct the OSGi folder structure, validate runmode naming, and redeploy configurations to ensure consistent behavior across pods.
Description description
Environment
- Adobe Experience Manager as a Cloud Service (AEMaaCS)
- Adobe Managed Services (AMS)
Issue/Symptoms
- OSGi configuration values do not appear in the vDeveloper Console after deployment.
- Multiple instances of the same PID appear, such as
com.day.cq.mailer.DefaultMailService, one per pod. - Configurations load only on Author or only on Publish depending on runmode.
- Preview values do not match Publish values, even though they inherit by default.
- New Developer Console UI shows stale values, while the classic view shows correct values.
Root cause
AEMaaCS resolves OSGi configurations from Git using strict runmode-based folder naming under the required repository path. Misplaced folders, incorrect runmode names, or deep nesting prevent configuration detection. Configurations load per pod through Sling JCR Installer, and Preview inherits Publish values. The new Developer Console UI may display stale values due to a known limitation.
Resolution resolution
Follow these steps to ensure correct OSGi configuration behavior and deployment:
- Navigate to the Git repository and verify that OSGi configurations are stored under
ui.config/src/main/content/jcr_root/apps/<project>/osgiconfig. - Ensure that configuration folders follow the correct runmode pattern, such as
config.publish,config.publish.stage, orconfig.author.dev. - Move any deeply nested configuration folders, such as
apps/project/test1/test2/config.authorto apps/<project>/osgiconfig/config.<runmode>to ensure detection. - Identify the target environment and ensure that the most specific runmode applies, for example
config.publish.stageoverridesconfig.publish. - Correct any mismatched runmode naming, such as
config.stg.publicto a valid pattern likeconfig.publish.stage. - Run the Cloud Manager pipeline associated with the
ui.configmodule to deploy configuration changes. - Verify configuration values in the Developer Console classic view because the newer UI may show stale data.
- Open the configuration view for All Authors or All Publishers and confirm that values appear grouped per pod.
- Redeploy the pipeline if only one pod shows updated values because temporary pod-level drift can occur.
- Remove any
config.preview.*folders so that Preview inherits values from Publish. - Use environment variables with the service set to preview if Preview-specific differentiation is required.
- Remove the
.cfg.jsonfile from Git and redeploy the pipeline to delete a configuration and reset it to the default. - Add
mode="replace"infilter.xmlif the configuration persists after deletion. - Ensure that configuration files include only required properties so that unspecified values fall back to defaults.
- Validate that all effective configuration values appear correctly across all pods in the Developer Console classic view.
When to escalate:
- Configuration values do not appear after validating the folder structure and redeploying the pipeline.
- Runmode resolution does not apply expected configuration values despite correct folder naming.
- Only some pods reflect updated configuration values after multiple deployments.
- Preview does not inherit Publish values after removing preview-specific configuration folders.
- Configuration deletion does not take effect after removing files and redeploying.
- Sling Installer does not process configuration resources as expected.