Posts tagged "OSGI"

June 9, 2016

config vs cfg – Battle royale

If you’ve been around AEM (and CQ) long enough, you’ve probably seen OSGi configurations serialized out in the form of a file. Its the easiest way to pre-configure various services and components in AEM. A common example is configuring a node and/or data store.

https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html

You’ll often find examples listing a files that have .cfg or .config extensions. Which leads me to the question:

Which format is the right one?

That is a bit tougher to answer. They both share generally the same patterns but have a few subtle differences.

CFG format:

  • Standard properties file format (java.util.Property)
  • Comments allowed
  • Only string values supported
    • A class name PropertiesUtil can convert (cast) values to their proper types. All common configurable classes available (OOTB) should use this utility and therefore should not be a big issue.

CONFIG format:

  • Introduced in the Felix framework in 2010 (see: https://issues.apache.org/jira/browse/FELIX-2513)
    • But not used directly by Sling until later (2011-ish+); CQ/AEM uses the Sling Launchpad Installer vs. the Felix FileInstall.
  • Supports typed values (boolean, Int, Float, Char, etc)
  • first line can be a comment (#example), but inline comments are not allowed
  • Various things need escaping
  • Multivalue properties are easier

A good explanation of the format can be found here:
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html

The configuration handler code which sets up the formatting:
https://github.com/apache/felix/blob/trunk/configadmin/src/main/java/org/apache/felix/cm/file/ConfigurationHandler.java

You can see examples of the CONFIG format persisted under the <install dir>/crx-quickstart/launchpad/config in a typical AEM instance.

Conclusion

The good news is that both formats are functional and supported. You don’t have to choose one versus the other. Although I’d advise against doing both interchangeably. Therefore, the guidance that I’d suggest is:

If you’re starting a new deployment/implementation, use CONFIG. Its the newer standard and provides more flexibility with regards to property config design.

If you’ve already deployed and have existing CFG files, stick with CFG. There appear to be no plans to remove/deprecate this format.

10:31 AM Permalink