[
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
[[email protected]] 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
[[email protected]] 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)
