[ 
https://issues.apache.org/jira/browse/SLING-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513095#comment-15513095
 ] 

Stefan Seifert edited comment on SLING-6059 at 9/22/16 12:08 PM:
-----------------------------------------------------------------

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 
features
{noformat}
/conf/global/feature/b
/conf/global/feature/a
/conf/global/feature/c
{noformat}
and site 1 wants to inherit all but "a":
{noformat}
/conf/site1/feature/
    + inherit=true
/conf/site1/feature/a
    + hide=true
{noformat}

or the first variant would be:
{noformat}
/conf/site1/feature/
    + inherit=true
    + hide=a
{noformat}
The other use case might be where you don't want to inherit all but just a few:
{noformat}
/conf/site1/feature/
    + inherit=b
{noformat}
vs
{noformat}
/conf/site1/feature/
/conf/site1/feature/b
    + inherit=true
{noformat}

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

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




was (Author: cziegeler):
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 
features
/conf/global/feature/b
/conf/global/feature/a
/conf/global/feature/c
and site 1 wants to inherit all but "a":
/conf/site1/feature/
    + inherit=true
/conf/site1/feature/a
    + hide=true

or the first variant would be:
/conf/site1/feature/
    + inherit=true
    + hide=a

The other use case might be where you don't want to inherit all but just a few:
/conf/site1/feature/
    + inherit=b
vs
/conf/site1/feature/
/conf/site1/feature/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
(v6.3.4#6332)

Reply via email to