Tag Archives: AEM config order

AEM Solution: How to override third-party OSGI Config in AEM

Overview

An overriding concept is a pretty known subject in AEM. Components can be overridden in an application with sling resolution technique. Similarly, Apache sling has a resolution order to resolve OSGi configs as well. Basically, application specific config’s can override AEM Libs configs. For more details on OSGI config & their resolution order, Read my posts here.

Scenarios/Problems

Let’s consider a scenario of a project where you have to use another AEM Project or third-party source code like ACS Commons. And, There are some services which you want to use but with different configuration. Assume services do have configurations in place.

Now you might be thinking that what is the big deal in that. We can upload third-party code & change the configuration. Well, That is the whole point. The moment you change the configuration for your application, One more maintenance issue happens. Got it? No?

No worry. The issue is that every time you update/install third-party code for your application, You have to manually change the configuration. You might think it is okay. But it is not when you have to support the same in every environment after every deployment. Someone has to fix every time. And what if the configuration has to be updated in prod publish environment. It is tough to maintain. Let me explain with config files.

#Thirdparty config’s XML File match for ContentFeed service under config.publish folder & apps folder is /apps/abc/thirdparty/. ContentFeed Service is part of platform code base.

#Base config: com.abc.core.contentFeed.xml
<?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"
    contentFeedPath="https://example.com/api/core/platform"/>

#Your application would like to override this config. And apps is /apps/myapp etc.

#Brand specific config: com.abc.core.contentFeed.xml

<?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"
    contentFeedPath="https://example.com/api/feed<myapp-feeds>"/>

Now, ContentFeed service does not pick your application-specific config & even though you have the same config in your application. It always picks up the third party config. And it happens ContentFeed service is part of platform source code.  I hope the problem is clear to you now. let’s see a solution.


General Solution

A general approach is to keep modifying third-party configs in every environment after each deployment. And, When QA reports this or that not working, a new person struggle to find why it is not working. Most of us do not remember that service configs are overridden by the deployment. The second approach is to override the full code itself with different service name & configurations. Must easy to maintain but having duplicate code & same bugs as third-party has. And fixing bugs every time something fixed in the third-party source.

Alternative Solution

Solution to above problem is simple. Make sure your app config file name is the same as third-party config. Read about XML config & service naming convention. AEM OSGi Config Resolution Order

To make sure Service picks your configuration, You need to create the same XML config under the same run mode folder & with additional run mode info because that is how AEM put precedence over other config’s. Let me explain with source code.

#Third-Party config file name is com.abc.core.contentFeed.xml
folder structure is: /apps/third-party/config.publish, config.author etc.

#Your app config name must be com.abc.core.contentFeed.xml
your Folder structure for config must be: /apps/third-party/config.publish.qa, /apps/third-party/config.publish.stage etc.

I hope the solution is clear to you. Solution seems easy but it solves general problem. Leave a comment if you have any question or feedback. thanks in advance.

AEM Solution: AEM OSGi Config Resolution Order

Overview

In this post, will talk about 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. Read the section “How these configs are resolved?” in this post How AEM OSGi works?

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

  • 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.
  • If you have made changes in 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.
  • 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.