Demonstrate sling:osgiConfig by runmodes

Image may be NSFW.
Clik here to view.
In some of our previous articles, we have made a passing reference to the Sling runmodes property; I have found upon occasion that there are Adobe Experience Manager developers and admins out there who don’t fully understand how these work. I am not going to go into all the information about runmodes—we will have a future series of articles from one of our Systems Engineers that will guide you through all of that. However, I’d like to at least introduce the concept here.

Runmodes can be used to help Sling determine which set of configuration options should be selected from within a given content repository. In this brief example, I’m going to show you how you can change a particular OSGi config back and forth with no changes to the code base or the JCR, but rather just by changing the arguments we pass to Adobe Experience Manager when it boots. At Axis41, our Managed Services team uses these runmodes extensively to empower our automation tooling.

In order to demonstrate the feature, I will be generating a small JSP file in my repo; it doesn’t really matter where. Here’s the JSP code:

<%@ page import="org.osgi.service.cm.Configuration, org.osgi.service.cm.ConfigurationAdmin" %><%
%><%@include file="/libs/foundation/global.jsp" %><%
    ConfigurationAdmin svc = sling.getService(org.osgi.service.cm.ConfigurationAdmin.class);
    Configuration conf = svc.getConfiguration("org.apache.sling.engine.impl.SlingMainServlet");
        %>
        

              The config for this pid says that "sling.max.calls" is 
              <%= conf.getProperties().get("sling.max.calls").toString() %>
        

This just gives us a page to read a specific OSGi Configuration; I picked one more or less at random. Normally, our components will read these values from a service, and those services will use a reference to the OSGi Configuration, so we don’t have to write all this code—I was just taking the cheap way out for a quick demonstration.

Now I’m going to create two different folders—config.publish.stage and config.prod; note that by putting multiple runmodes in the folder name, I restrict it down further. That is to say, “config.prod” would apply to any node that has the runmode “prod” (our Production lane)—whether Author or Publish—while “config.publish.stage” would only apply to Publish instances in the Stage lane.
Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

As you can see, each of these folders has a single “sling:osgiConfig” node inside it, and the name of that node is the same as the Service PID we are trying to configure (org.apache.sling.engine.impl.SlingMainServlet). An additional property is added to the node to set the config property we want to customize based on the runmodes (sling.max.calls). When our active runmode is “prod”, we’d like it set to 1750, while we want it at 1575 in the Publish instances using the “stage” runmode.

When we start the AEM instance with the runmodes “publish,stage” and load the page we created to dump the value, we should see output that looks something like this:
Image may be NSFW.
Clik here to view.

Now we can stop AEM and start it with the runmode “publish,prod” and confirm that the value indeed updates to the new setting:
Image may be NSFW.
Clik here to view.

In a real-world scenario, there are a handful of configs that we almost ALWAYS want to set differently based on the lane (Prod, Stage, Dev, etc.); some examples include loggers, JCR Resource Resolver (used to power the “/etc/map” system; this is often used for mapping domains to content paths) mailer configs, LDAP server names, and search engine settings.

Hopefully this has introduced to you the power of Sling’s runmode, and stay tuned to aempodcast.com for a much more in-depth discussion of how these can be leveraged to manage your Adobe Experience Manager stack.