[
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)
