[ 
https://issues.apache.org/jira/browse/SLING-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert updated SLING-6059:
----------------------------------
    Description: 
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).

  was:
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-6062). 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).


> Context-Aware Config: Rethink resource inheritance for configuration 
> collections
> --------------------------------------------------------------------------------
>
>                 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