Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Read AEM runmodes from Sightly
var SlingSettingsService = Packages.org.apache.sling.settings.SlingSettingsService;
use(function () {
// Get runmodes and transform them into an object that is easier to read for Sightly
var runmodesObj = {};
var runmodesSet = sling.getService(SlingSettingsService).getRunModes();
var iterator = runmodesSet.iterator();
while (iterator.hasNext()) {
runmodesObj[iterator.next()] = true;
}
return {
runmodes: runmodesObj
}
});
<div data-sly-use.logic="logic.js">
<p>Current runmodes: ${logic.runmodes}</p>
<p data-sly-test="${logic.runmodes.samplecontent}">samplecontent runmode</p>
</div>
@gabrielwalt

This comment has been minimized.

Copy link
Owner Author

commented May 13, 2015

FYI, for those who don't know the REPL tool yet, you can easily experiment with such scripts in the Sightly live execution environment called REPL (which stands for Read Eval Print Loop):
https://github.com/Adobe-Marketing-Cloud/aem-sightly-repl

@gabrielwalt

This comment has been minimized.

Copy link
Owner Author

commented May 13, 2015

Important note: runmodes cannot change after install and are meant to trigger OSGi configs and bundles, code should not act on them! This means that the above example should be used wisely.
thanks @alexkli for the comment

@steeleforge

This comment has been minimized.

Copy link

commented May 14, 2015

Custom run-modes -can- change after install, but not some of the baked in AEM run-modes: author/publish/crx2/crx3tar/etc

But as you precisely mentioned, it is very common to append custom runmodes to specify a logical instance e.g. publish,dev vs publish,prod1 etc then target sling:OsgiConfig nodes for OSGi service configurations as part of a build artifact. After one upacks the jar, they can easily adds custom run modes to their start shell/batch script, the custom run-modes and confirm these felix (/system/console/status-slingsettings)

@paulrohrbeck

This comment has been minimized.

Copy link

commented Mar 23, 2016

@gabrielwalt If code should not act on the run mode, what's your suggestion for handling a scenario where different code is needed between a stage and prod environment? Adding an OSGi config just to distinguish the two and then using that in Sightly seems a bit overkill.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.