Stefan Seifert commented on SLING-6059:

hmm, this can quickly get as complex as the sling resource merger with 
hiding/allowing a list of resources by it's name.

i thought about a much simpler solution (as it is supported by the AEM ConfMgr 
* by default, no configuration lists are merged if you overwrite a named 
configuration on a more specific level (e.g. "feature")
* if you set a "merge" property to true then the resource list on the current 
level is merged with the list on the next-higher level (name duplicates are 
* same logic could be applied to property merging on property level (SLING-6058)


* for "site1/feature" you get: a,d
* for "site2/feature" your get a,b,c
* if you set a "merge=true" property on /conf/site1/feature you will get a,b,c,d
* for all other usecases you still need to copy what you need and to not set 
* we may support the merged property on both sides, and merging applies if one 
or both sides have set merging=true, and is not applied if the most-specific 
level defines merging=false

if we are sure we need more complexity and control on the inheritance, we 
perhaps should use the resource merger syntax (or the resource merger impl 
itself), instead inventing another complex inheritance description language.

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> ------------------------------------------------------------------------------------------
>                 Key: SLING-6059
>                 URL: https://issues.apache.org/jira/browse/SLING-6059
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>            Reporter: Stefan Seifert
>            Assignee: Stefan Seifert
>              Labels: contextaware-config
>             Fix For: Context-Aware Configuration 1.0.0
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).

This message was sent by Atlassian JIRA

Reply via email to