...
The columns "OSGi", "ConfMgr" and "wcm.io Conf" describe if the existing implementations already cover this use case.
The last column "two columns "Sling Conf" and "wcm.io Conf V2" defines if this use cases should be covered by the new solution split up in Sling and wcm.io, and with which priority.
Use Cases
| Use Case | OSGi | ConfMgr | CSC | wcm.io Conf |
|---|
| Sling CAConf | wcm.io CAConf |
|---|---|
A) Configuration Hierarchy |
A1) Global Configuration |  | |  | |
| ||||
| A2) Default values for global configurations | | | | |
| |||
| A3) Configuration levels based on content hierarchy | | | |
|
| |||||
A4) Nesting of configuration levels with parameter inheritance (object/resource-level) | | | | |
|
| A5) Nesting of configuration levels with parameter inheritance (property-level) | | | | |
| |
| A6) Explicit linking of content with config hierarchy via property in content nodes | | | |
|
| ||||
| A7) Declarative linking of content with config hierarchy via configuration | | | | |
| ||||
| A8) Declarative linking of content with config hierarchy via pluggable strategies | | | | |
| |
B) Describing configurations |
| B1) Bundles provide metadata which configuration parameters are available | | | |
|
| ||
| B2) Parameter definitions with Parameter Group, Name, Data Type and Default Value | | | |
|
| ||
| B3) Multi-valued parameter type (Array) | | | |
|
| ||||
| B4) Map parameter type (Key/Value pairs) | | | | |
| |||
| B5) Parameter metadata for Edit GUIs like labels, descriptions, list options | | | |
|
| |||||||||||||
| B6) i18n Support for parameter metadata for Edit GUIs | | | | |
| |||||||||
| B7) Define lists of parameter groups (like OSGi factory configs) | | | | |
| |||
| B8) Define parameters via typed annotation classes | | | |
|
| ||||||||||||||
| B9) Distinction between technical/infrastructure and business/application parameters | | | | |
| |||||||||
C) Reading configurations (API) |
| C1) Access configurations via dedicated service interface | | | | |
| ||||
C2) Access configurations via adaptTo() | | | | |
| |||
| C3) Parameters are divided in groups/sections accessible individually | | | |
|
| |||
| C4) Support of nested parameter groups/deep hierarchies | | | |
|
| ||
| C5) Support list of parameter groups (like OSGi factory configs) | | | |
|
| ||
| C6) Support merging of lists of parameter groups along with inheritance | | | |
|
| |||
| C7) Access parameters as key/value maps (Map) | | | |
|
| |||
| C8) Access parameters as ValueMap with easy type conversion | | | |
|
| |||
| C9) Access parameters via Resource wrapper | | | | |
| |||
| C10) Access parameters via typed annotation classes | | | |
|
| |||
| C11) Direct access to configuration parameters in HTL/Sightly bindings | | | | |
| ||||
| C12) Easy access to configuration parameters in Sling Models | | | | |
| |||
| C13) Easy access to configuration parameters in OSGi services | | | |
|
| |||||
| C14) Support lowlevel access to other configuration-like resource structures beyond configuration parameter lists (e.g. workflow configurations) | | | | |
| |
D) Storing configurations |
| D1) Store configuration in repository | | | |
|
| ||||
| D2) Store configuration in hierarchies linked to content | | | | |
| |||
D3) Store configuration in folder separate from content like /conf | | | |
|
| |||
D4) Store configuration together with content in /content | | | | |
| | |||
| D5) Pluggable storage strategies | | | | |
| ||||||||||||||
| D6) Store technical/infrastructure parameter on different location than business/application parameters | | | | |
| |||||||||
E) Managing Configurations |
| E1) Provide configuration management API for reading and writing configuration | | | | |
| |||
| E2) Provide GUI editor to edit configurations | | | |
|
|
| |||
| E3) Provide web console plugin for inspecting configurations | | | |
|
| ||||||||||
| E4) Allow to lock parameter values on a certain configuration hierarchy level to disallow overriding it on deeper levels | | | | |
| |||||
| E5) Configuration change listener - notification when configuration changes | | | | |
|
|
| |||
F) Parameter overriding |
F1) Allow overriding content-specific parameters via OSGi configuration | | | | |
| ||||
| F2) Allow overriding content-specific parameters via JVM system environment parameters | | | | |
| ||||||||||||||
| F3) Allow overriding content-specific parameters via request header (activate only on test instances) | | | | |
| |||||||||
G) AEM-specific features |
G1) Support storing configurations in cq:Page nodes due to support around this (versioning, replication etc.) | | | |
|
| ||||
| G2) Configuration editor integrated in AEM Touch UI | | | | |
| |
H) Advanced Features |
| H1) Switch configurations depending on Sling Run Modes | | | | |
| ||||
| H2) Support different configuration hierarchy/persistence strategies for different applications deployed in the same instance | | | | |
| ||||
| H3) Placeholders within configuration values to reference other parameters | | | | |
| |||
| H4) Multi tenancy-support | | | |
|
| ||||||||||||||
| H5) Multi tenancy-support with full isolation | | | | |
| |||||||||
| H6) Security: Easy protection of configuration via ACLs | | | | / |
| ||||||
| H7) Detect "AEM Site root" via configuration (most times the most-inner configuration scope) | | | | | |