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 ".

Configuration of OSGi services can be done with:

1. Adobe AEM Web console
2. Configuration Files
3. Content nodes

• UI to configure components
• changes are applied immediately to the instance, no matter what the run modes are (changing the run mode will not change the config either)
• path to the config console: /system/console/configMgr
• saved config will be applied right away, no restart required
• updates saved in repository as config file under /apps, Persistent Identity (PID) will be used as file name

• .config files saved in repository under /apps
• config file format is not human friendly so it's recommended to use web console to edit those files
• can be saved in content package and applied to other instance
• config file location can be found with a SQL2 query like: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/apps]) AND contains(*, 'org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl'), this would find all configs for Resource Resolver factory, for example file org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl.config with jcr:primaryType nt:file and content similar to:

# Configuration created by Apache Sling JCR Installer
resource.resolver.required.providernames=["JCR"]
resource.resolver.manglenamespaces=B"true"
resource.resolver.optimize.alias.resolution=B"true"
resource.resolver.vanitypath.blacklist=["/content/usergenerated"]
resource.resolver.vanity.precedence=B"false"
resource.resolver.vanitypath.maxEntries=I"-1"

• nodes with sling:OsgiConfig primary types
• changing the node property will update the OSGI config (as if the changes were made with web console), this also applies when config file is copied from libs to apps
• can be applied per run mode
• config files must be a child of the nt:folder with name starting with config, for example config, config.author, config.author.int, config.publish.prod

1. Get PID of the service to configure
2. Decide on which run modes config should be applied and create directory config.<run-mode> with type nt:folder
3. Create node of type sling:OsgiConfig and name equal to service PID
4. For each param create a property of the node, name of the parameter can be copied from web console, select correct type and put the desired value
5. 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).

Factory configuration

When making a Factory Configuration append -<identifier> to the name. As in: org.apache.sling.commons.log.LogManager.factory.config-<identifier> Where <identifier> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information); for example:

• org.apache.sling.commons.log.LogManager.factory.config-custom-for-project

1. Repository nodes under /apps/*/config... .either with type sling:OsgiConfig or property files.
2. Repository nodes with type sling:OsgiConfig under /libs/*/config... . (out-of-the-box definitions).
3. Any .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 /apps.

Configuration changes made while the system is running trigger a reload with the modified configuration.

Then the following order of precedence applies:

1. Modifying a configuration in the Web console will take immediate effect as it takes precedence at runtime.
2. Modifying a configuration in /apps will take immediate effect.
3. Modifying a configuration in /libs will take immediate effect, unless it is masked by a configuration in /apps

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.

Example 1 Instance started with run modes: author,dev,osgitest Configuration under following directories will be applied:

• /apps/*/config.osgitest
• /apps/*/config.author.dev/
• /apps/*/config.author.osgitest.dev

Configuration under following directories will not be applied:

• /apps/*/config.author.other/
• /config/author.dev.osgitest.noldap/ - more run modes that the instance has

Multiple configuration example

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 entier PID.

Changes done with Web console are (usually) saved in the repository at /apps/<some-directory>, by default under /apps/system/config. If config changed was initially saved in different location for example /libs/foo/config/someconfig than the updated config will be saved under /apps/foo/config/someconfig

Settings that are changed by admin are saved in *.config files under: /crx-quickstart/launchpad/config

• 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 *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/org/apache/felix/webconsole/internal/servlet/OsgiManager.config

CRX Sling Client Repository ../com/day/crx/sling/client/impl/CRXSlingClientRepository/<pid-nr>.config

By default directory crx-quickstart/install is watched for files. This folder does not exist, but simply can be created at runtime. If a bundle, configuration or content package is put into this directory, it is automatically picked up and installed. If it's removed, it gets uninstalled. It is another way to put bundles, content packages or configurations to the repository. This might be useful in development or when the web console is not available.

• Configuring OSGi