You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2016/11/03 12:20:55 UTC
[CAConfig] Spezialized inheritance handling
Hi,
while comparing Adobe's confmgr with our CA configurations, there is one
difference with inheritance handling.
In Sling there is no way to specify to not inherit a configuration if
inheritance is enabled, e.g.
/conf/foo/sling:configs/a
/b
/conf/foo/subproject/sling:configs/c
+sling:configCollectionInherit=true
If you now have the use case, that you want a list of "a" and "c" for a
context resource pointing to "/conf/foo/subproject" there is no way to
handle this wit CA configurations.
On the other hand confmgr uses a very subtle approach:
you can create a node at /conf/foo/subproject/sling:configs/b with no
jcr:content sub node and this will block inheritance for "b". It also
means that as soon as you use inheritance, you have to use jcr:content
sub nodes. So in the example above at least "c" needs to have one.
I think this mechanism is too much magic to add it to CA configs,
however it would be great to have some hook or SPI on dealing with it
through the CA implementation.
So far I couldn't come up with any good apprach. Anyone have an idea?
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [CAConfig] Spezialized inheritance handling
Posted by Carsten Ziegeler <cz...@apache.org>.
I've created SLING-6244 and added a first SPI updated and
implementation. Please let me know what you think.
Regards
Carsten
Stefan Seifert wrote
>> Stefan Seifert wrote
>>> is this a "general SPI", or an SPI provided by
>> DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd
>> level SPI"? not nice, but yes I think as well there is no nice way to
>> support this exotic use case without duplicating the
>> DefaultConfigurationResourceResolvingStrategy which we want to avoid.
>>>
>>> the interface name should somewhat make clear that it handles resource
>> collection inheritance, not property inheritance.
>>> e.g. something like CollectionInheritanceDecider.
>>>
>> Good point, it could be a general SPI which is used by all resolving
>> stragies.
>
> ok
>
> stefan
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [CAConfig] Spezialized inheritance handling
Posted by Stefan Seifert <ss...@pro-vision.de>.
>Stefan Seifert wrote
>> is this a "general SPI", or an SPI provided by
>DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd
>level SPI"? not nice, but yes I think as well there is no nice way to
>support this exotic use case without duplicating the
>DefaultConfigurationResourceResolvingStrategy which we want to avoid.
>>
>> the interface name should somewhat make clear that it handles resource
>collection inheritance, not property inheritance.
>> e.g. something like CollectionInheritanceDecider.
>>
>Good point, it could be a general SPI which is used by all resolving
>stragies.
ok
stefan
Re: [CAConfig] Spezialized inheritance handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
> is this a "general SPI", or an SPI provided by DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd level SPI"? not nice, but yes I think as well there is no nice way to support this exotic use case without duplicating the DefaultConfigurationResourceResolvingStrategy which we want to avoid.
>
> the interface name should somewhat make clear that it handles resource collection inheritance, not property inheritance.
> e.g. something like CollectionInheritanceDecider.
>
Good point, it could be a general SPI which is used by all resolving
stragies.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [CAConfig] Spezialized inheritance handling
Posted by Stefan Seifert <ss...@pro-vision.de>.
is this a "general SPI", or an SPI provided by DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd level SPI"? not nice, but yes I think as well there is no nice way to support this exotic use case without duplicating the DefaultConfigurationResourceResolvingStrategy which we want to avoid.
the interface name should somewhat make clear that it handles resource collection inheritance, not property inheritance.
e.g. something like CollectionInheritanceDecider.
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Friday, November 4, 2016 3:02 PM
>To: Sling Developers
>Subject: Re: [CAConfig] Spezialized inheritance handling
>
>I've thought about this a little bit more, what about we provide a SPI
>interface used by DefaultConfigurationResourceResolvingStrategy.
>
>Something along these lines:
>
>interface InheritanceDecider {
>
> enum DECISION {
> INCLUDE,
> EXCLUDE,
> BLOCK
> }
>
> DECISION decide(String bucketName, Resource resource);
>
>}
>
>So for every item found in getResourceCollection this optional service
>is asked. If it returns INCLUDE the resource is included, if it returns
>EXCLUDE it is excluded, but a parent can provide this resource. If it
>returns BLOCK, it's excluded and no parent can provide this resource.
>
>WDYT?
>
>Regards
>Carsten
>
>
>Carsten Ziegeler wrote
>> Hi,
>>
>> while comparing Adobe's confmgr with our CA configurations, there is one
>> difference with inheritance handling.
>> In Sling there is no way to specify to not inherit a configuration if
>> inheritance is enabled, e.g.
>> /conf/foo/sling:configs/a
>> /b
>>
>> /conf/foo/subproject/sling:configs/c
>> +sling:configCollectionInherit=true
>>
>> If you now have the use case, that you want a list of "a" and "c" for a
>> context resource pointing to "/conf/foo/subproject" there is no way to
>> handle this wit CA configurations.
>>
>> On the other hand confmgr uses a very subtle approach:
>> you can create a node at /conf/foo/subproject/sling:configs/b with no
>> jcr:content sub node and this will block inheritance for "b". It also
>> means that as soon as you use inheritance, you have to use jcr:content
>> sub nodes. So in the example above at least "c" needs to have one.
>>
>> I think this mechanism is too much magic to add it to CA configs,
>> however it would be great to have some hook or SPI on dealing with it
>> through the CA implementation.
>>
>> So far I couldn't come up with any good apprach. Anyone have an idea?
>>
>> Carsten
>>
>
>
>
>
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: [CAConfig] Spezialized inheritance handling
Posted by Carsten Ziegeler <cz...@apache.org>.
I've thought about this a little bit more, what about we provide a SPI
interface used by DefaultConfigurationResourceResolvingStrategy.
Something along these lines:
interface InheritanceDecider {
enum DECISION {
INCLUDE,
EXCLUDE,
BLOCK
}
DECISION decide(String bucketName, Resource resource);
}
So for every item found in getResourceCollection this optional service
is asked. If it returns INCLUDE the resource is included, if it returns
EXCLUDE it is excluded, but a parent can provide this resource. If it
returns BLOCK, it's excluded and no parent can provide this resource.
WDYT?
Regards
Carsten
Carsten Ziegeler wrote
> Hi,
>
> while comparing Adobe's confmgr with our CA configurations, there is one
> difference with inheritance handling.
> In Sling there is no way to specify to not inherit a configuration if
> inheritance is enabled, e.g.
> /conf/foo/sling:configs/a
> /b
>
> /conf/foo/subproject/sling:configs/c
> +sling:configCollectionInherit=true
>
> If you now have the use case, that you want a list of "a" and "c" for a
> context resource pointing to "/conf/foo/subproject" there is no way to
> handle this wit CA configurations.
>
> On the other hand confmgr uses a very subtle approach:
> you can create a node at /conf/foo/subproject/sling:configs/b with no
> jcr:content sub node and this will block inheritance for "b". It also
> means that as soon as you use inheritance, you have to use jcr:content
> sub nodes. So in the example above at least "c" needs to have one.
>
> I think this mechanism is too much magic to add it to CA configs,
> however it would be great to have some hook or SPI on dealing with it
> through the CA implementation.
>
> So far I couldn't come up with any good apprach. Anyone have an idea?
>
> Carsten
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org