Stefan Seifert commented on SLING-6026:

this is a rather big change, PR is https://github.com/apache/sling/pull/174
it includes the changes for SLING-6023 as well and extends them.

what's in the PR:
* SPI for the ConfigurationResolver
** ConfigurationPersistenceStrategy to define how configuration data is stored 
(e.g. subnods, resource type etc.) - only for configuration data, not for other 
configuration resources in general
* SPI for the ConfigurationResourceResolver
** ContextPathStrategy: strategy how context paths are detected - via 
sling:config-ref parameters or implicitly or a combination (from SLING-6023)
** ConfigurationResourceResolvingStrategy: strategy where the configuration is 
stored, with what inheritance and defaulting mechanisms
* for all SPI interfaces default implementaions exist and are active by default 
that function identically to the previous implementation
* all SPIs have the same feature that it is possible to register multiple 
implementations and so only adapt or extend the behavior on certain parts 
without having to switch off the default functionality. this is done by 
"multiplexer" services for each SPI federating between the implementations 
orderd by service ranking.
* additionally there is a "Management API" which is not in the API bundle but 
in the impl bundle because it near to the implementation. its only dedicated 
for special use case e.g. implementing a configuration editor GUI, not for 
"normal" client applications. it allows to read and write configuration data 
using the mentioned SPI strategies.

> Context-Aware Config: Pluggable configuration persistence
> ---------------------------------------------------------
>                 Key: SLING-6026
>                 URL: https://issues.apache.org/jira/browse/SLING-6026
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Stefan Seifert
>            Assignee: Stefan Seifert
>             Fix For: Context-Aware Configuration 1.0.0
> currently configuration data is only read, and it's hard-coded how it's 
> stored in the configuration resource (properties directly in the resource).
> we need to enhance this to provide a management API to read+write 
> configuration data (required for configuration editor GUIs).
> additional the details of the persistence should be pluggable with a simple 
> default implementation which can be similar to what is present today. but in 
> more complex environments it may be desired to:
> * use special node types to store the configuration in (e.g. to make sure 
> they are stored in an index)
> * use a jcr:content subnode to store configuration data in
> * assign special resource types to support a configuration editor
> * decide in which path the configurations are stored

This message was sent by Atlassian JIRA

Reply via email to