...
Use Case | OSGi | ConfMgr | wcm.io Conf | |||
---|---|---|---|---|---|---|
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 | ||||||
A5) Explicit linking of content with config hierarchy via property in content nodes | ||||||
A6) Declarative linking of content with config hierarchy via configuration | ||||||
A7) 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 Sightly bindings | ||||||
C12) Easy access to configuration parameters in Sling Models | ||||||
C13) Easy access to configuration parameters in OSGi services | ||||||
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 Configurationsand GUI Tools | ||||||
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 | ||||||
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 | ||||||
F) Advanced Configuration 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 | / |