OSGi is a fundamental element in the technology stack of Adobe Experience Manager (AEM). It is used to control the composite bundles of AEM and their configuration.
OSGi “provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed”.
This allows easy management of bundles as they can be stopped, installed, started individually. The interdependencies are handled automatically. Each OSGi Component (see the OSGi Specification) is contained in one of the various bundles.
You can manage the configuration settings for such bundles by either:
sling:OsgiConfig) in the repository
Either method can be used though there are subtle differences, primarily in relation to Run Modes:
The Web Console is the standard interface for OSGi configuration. It provides a UI for editing the various properties, where possible values can be selected from predefined lists.
As such it is the easiest method to use.
Any configurations made with the Web Console are applied immediately and applicable to the current instance, irrespective of the current run mode, or any subsequent changes to the run mode.
sling:OsgiConfignodes, you can tie the configuration to a specific run mode. You can even save configurations for more than one run mode in the same repository.
Whichever method you use, all of these configuration methods:
Details of certain important settings are listed under OSGi Configuration Settings.
The Web console in AEM provides a standardized interface for configuring the bundles. The Configuration tab is used for configuring the OSGi bundles, and is therefore the underlying mechanism for configuring AEM system parameters.
Any changes made are immediately applied to the relevant OSGi configuration, no restart is required.
Changes made in the web console are saved in the repository as configuration files. These can be included in content packages for re-use in further installations.
On the Web console any descriptions that mention default settings relate to Sling defaults.
Adobe Experience Manager has its own defaults and so the defaults set might differ from those documented on the console.
To update a configuration with the web console:
Access the Configuration tab of the Web Console by either:
Opening the web console from the link on the Tool -> Operations menu. After logging into the console you can use the drop-down menu of:
The direct URL; for example:
A list will be shown.
Select the bundle that you want to configure by either:
A dialog will open. Here you can edit as required; for example, set the Log Level to
Updates are saved in the repository as configuration files. To locate these afterwards, (e.g. to include in a content package for use on another instance) you should make a note of the persistent identity (
Your changes are immediately applied to the relevant OSGi configuration of the running system, no restart is required.
You can now locate the related configuration file(s); for example, to include in a content package for use on another instance.
Configuration changes made using the Web Console are persisted in the repository as configuration files (
These can be included in content packages and re-used on other instances.
The format of the configuration files are very specific - see the Sling Apache documentation for full details.
For this reason it is recommended to create and maintain the configuration file by making actual changes in the web console.
The Web Console shows no indication of where in the repository your changes have been saved, but they can be easily located:
Create the configuration file by making an initial change in the web console.
Open CRXDE Lite.
In the Tools menu select Query … .
Submit a query of Type
SQL to search for the PID of the configuration that you have updated.
For example, Apache Felix OSGi Management Console has the persistent identity (PID) of:
So the SQL query could be:
select * from nt:base where jcr:path like '/apps/%' and contains(*, 'org.apache.felix.webconsole.internal.servlet.OsgiManager')
The configuration file node will be shown.
For the above example:
You can open this file to view your changes, but to avoid typing errors it is recommended to make actual changes with the console.
You can now build a content package, containing this node, and use as required on your other instances.
In addition to using the web console, you can also define configuration details in the repository. This allows you to easily configure your differing run modes.
These configurations are made by creating
sling:OsgiConfig nodes in the repository for the system to reference. These nodes mirror the OSGi configurations, and form a user interface to them. To update the configuration data you update the node properties.
If you modify the configuration data in the repository the changes are immediately applied to the relevant OSGi configuration as if the changes had been made using the Web console, with the appropriate validation and consistency checks. This also applies to the action of copying a configuration from
As the same configuration parameter can be located in several places, the system:
To add a new configuration to the repository you need to know the following:
The Persistent Identity (PID) of the service.
Reference the Configurations field in the Web console. The name is shown in brackets after the bundle name (or in the Configuration Information towards the bottom of the page).
For example, create a node
com.day.cq.wcm.core.impl.VersionManagerImpl. to configure AEM WCM Version Manager.
Whether a specific run mode is required. Create the folder:
config- for all run modes
config.author- for the author environment
config.publish- for the publish environment
config.<run-mode>- as appropriate
Whether a Configuration or Factory Configuration is necessary.
The individual parameters to be configured; including any existing parameter definitions that will need to be recreated.
Reference the individual parameter field in the Web console. The name is shown in brackets for each parameter.
For example, create a property
versionmanager.createVersionOnActivation to configure Create Version on Activation.
Does a configuration already exist in
/libs? To list all configurations in your instance, use the Query tool in CRXDE Lite to submit the following SQL query:
select * from sling:OsgiConfig
If so, this configuration can be copied to
/apps/<yourProject>/, then customized in the new location.
To actually add the new configuration to the repository:
Use CRXDE Lite to navigate to:
If not already existing, create the
config folder (
config- applicable to all run modes
config.<run-mode>- specific to a particular run mode
Under this folder create a node:
Name: the persistent identity (PID);
for example for AEM WCM Version Manager use
When making a Factory Configuration append
-<identifier> to the name.
<identifier> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information); for example:
For each parameter that you want to configure, create a property on this node:
Create Version on Activationuse
You only need to create properties for the parameters that you want to configure, others will still take the default values as set by AEM.
Save all changes.
Changes are applied as soon as the node is updated by restarting the service (as with changes made in the Web console).
You must not change anything in the
The full path of a configuration must be correct for it to be read at startup.
The following order of precedence is used:
Repository nodes under
/apps/*/config....either with type
sling:OsgiConfig or property files.
Repository nodes with type
/libs/*/config.... (out-of-the-box definitions).
.config files from
<*cq-installation-dir*>/crx-quickstart/launchpad/config/.... on the local file system.
This means that a generic configuration in
/libs can be masked by a project specific configuration in
Configuration changes made while the system is running trigger a reload with the modified configuration.
Then the following order of precedence applies:
/appswill take immediate effect.
/libswill take immediate effect, unless it is masked by a configuration in
For run mode specific configurations, multiple run modes can be combined. For example, you can create configuration folders in the following style:
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.author.emea.dev/ will be applied, while configuration nodes in
/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.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 entier PID.
The following list shows a small selection of the configurations available (in a standard installation) in the repository:
Author - AEM WCM Filter:
Publish - AEM WCM Filter:
Publish - AEM WCM Page Statistics:
As these configurations reside in
/libs they must not be edited directly, but copied to your application area (
/apps) before customization.
To list all configuration nodes in your instance, use the Query functionality in CRXDE Lite to submit the following SQL query:
select * from sling:OsgiConfig
If you change a configuration through the Web console, it is (usually) written into the repository at:
system/config so the configuration is written to
However, if you are editing a configuration which initially came from elsewhere in the repository: for example:
Then the updated configuration is written under the original location; for example:
Settings that are changed by
admin are saved in
*.config files under:
This is the private data area of the OSGi configuration admin and holds all configuration details specified by
admin, regardless how they entered the system.
This is an implementation detail and you must never edit this directory directly.
However, it is useful to know the location of these configuration files so that copies can be taken for backup and/or multiple installation:
Apache Felix OSGi Management Console
CRX Sling Client Repository
You must never edit the folders or files under: