Carsten Ziegeler commented on SLING-6059:

One common use case is adding/overwriting exhisting configurations, for example 
health checks. There will be predefined HCs somewhere under libs/ and in /conf 
you can override them, usually adding your own. Clearly you don't want to 
repeat/copy all of the existing ones.
So for the example above, a "inherit=true" property on the feature resource 
would do the trick.
But I assume there a some use cases where you want to inherit all but not some 
explicit ones, we could add a property listing those names on the feature 
resource or provide a special resource type, for example - we have three global 
and site 1 wants to inherit all but "a":
    + inherit=true
    + hide=true

or the first variant would be:
    + inherit=true
    + hide=a

The other use case might be where you don't want to inherit all but just a few:
    + inherit=b
    + inherit=true

Of course we have to come up with better property names, this is just to 
illustrate the possibilites

[~sseif...@pro-vision.de] WDYT?

> 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