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 08:51:28 UTC
[CAConfig] Provide an SPI for transformation of config refs
Hi,
the current mechanism (implemented in
DefaultConfigurationResourceResolvingStrategy) uses the value from the
sling:confRef property and validates it against some built-in rules.
One of them is discarding relative paths.
We would like to have a hook/SPI for allowing relative paths and for
further validation like if the sling:confRef property contains the
bucketName "sling:configs", the value should be discarded.
So basically what I'm thinking of is an interface with a single method
taking the ContextResource and the bucket name and returning a string
(absolute path) or null.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [CAConfig] Provide an SPI for transformation of config refs
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote
> Stefan Seifert wrote
>>> a) If the value from the sling:confRef property ends with the bucket
>>> name, then a warning is logged and this value is ignored
>>>
>>> b) If the value from the sling:confRef property is relative, the parent
>>> hierarchy of the context resource is traversed up to find a context
>>> resource with an absolute property. Once found, these are concatenated.
>>> For example
>>> /content/a
>>> + sling:confRef=/conf/a
>>> /content/a/b
>>> + sling:confRef=b
>>>
>>> If you try to find configurations for /content/a/b it searches in
>>> /conf/a/b first, then /conf/a
>>
>> ah, ok.
>> from my side it would be ok to implement both directly in the DefaultConfigurationResourceResolvingStrategy, they sound reasonable.
>> otherwise via the separate SPI for usecase b), usecase a) makes sense in any way.
>>
> Ok, thanks Stefan
>
> I'll create an issue and provide an implementation in
> DefaultConfigurationResourceResolvingStrategy for both then. We can then
> still decide whether we leave it like that or create the SPI
>
I've created SLING-6239 and SLING-6240
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [CAConfig] Provide an SPI for transformation of config refs
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
>> a) If the value from the sling:confRef property ends with the bucket
>> name, then a warning is logged and this value is ignored
>>
>> b) If the value from the sling:confRef property is relative, the parent
>> hierarchy of the context resource is traversed up to find a context
>> resource with an absolute property. Once found, these are concatenated.
>> For example
>> /content/a
>> + sling:confRef=/conf/a
>> /content/a/b
>> + sling:confRef=b
>>
>> If you try to find configurations for /content/a/b it searches in
>> /conf/a/b first, then /conf/a
>
> ah, ok.
> from my side it would be ok to implement both directly in the DefaultConfigurationResourceResolvingStrategy, they sound reasonable.
> otherwise via the separate SPI for usecase b), usecase a) makes sense in any way.
>
Ok, thanks Stefan
I'll create an issue and provide an implementation in
DefaultConfigurationResourceResolvingStrategy for both then. We can then
still decide whether we leave it like that or create the SPI
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [CAConfig] Provide an SPI for transformation of config refs
Posted by Stefan Seifert <ss...@pro-vision.de>.
>a) If the value from the sling:confRef property ends with the bucket
>name, then a warning is logged and this value is ignored
>
>b) If the value from the sling:confRef property is relative, the parent
>hierarchy of the context resource is traversed up to find a context
>resource with an absolute property. Once found, these are concatenated.
>For example
>/content/a
> + sling:confRef=/conf/a
>/content/a/b
> + sling:confRef=b
>
>If you try to find configurations for /content/a/b it searches in
>/conf/a/b first, then /conf/a
ah, ok.
from my side it would be ok to implement both directly in the DefaultConfigurationResourceResolvingStrategy, they sound reasonable.
otherwise via the separate SPI for usecase b), usecase a) makes sense in any way.
stefan
Re: [CAConfig] Provide an SPI for transformation of config refs
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
> sounds basically ok to me.
>
> of course we could check first if the tweaks we want to enable using this SPI might be as well directly implemented in the DefaultConfigurationResourceResolvingStrategy, if they are a good addition to the general default behavior.
>
> if the usecases are too exotic for the "mainstream" such an SPI makes sense.
>
Right, so basically we have two use cases:
a) If the value from the sling:confRef property ends with the bucket
name, then a warning is logged and this value is ignored
b) If the value from the sling:confRef property is relative, the parent
hierarchy of the context resource is traversed up to find a context
resource with an absolute property. Once found, these are concatenated.
For example
/content/a
+ sling:confRef=/conf/a
/content/a/b
+ sling:confRef=b
If you try to find configurations for /content/a/b it searches in
/conf/a/b first, then /conf/a
Regards
Carsten
> stefan
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: Thursday, November 3, 2016 9:51 AM
>> To: Sling Developers
>> Subject: [CAConfig] Provide an SPI for transformation of config refs
>>
>> Hi,
>>
>> the current mechanism (implemented in
>> DefaultConfigurationResourceResolvingStrategy) uses the value from the
>> sling:confRef property and validates it against some built-in rules.
>> One of them is discarding relative paths.
>>
>> We would like to have a hook/SPI for allowing relative paths and for
>> further validation like if the sling:confRef property contains the
>> bucketName "sling:configs", the value should be discarded.
>>
>> So basically what I'm thinking of is an interface with a single method
>> taking the ContextResource and the bucket name and returning a string
>> (absolute path) or null.
>>
>> WDYT?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [CAConfig] Provide an SPI for transformation of config refs
Posted by Stefan Seifert <ss...@pro-vision.de>.
sounds basically ok to me.
of course we could check first if the tweaks we want to enable using this SPI might be as well directly implemented in the DefaultConfigurationResourceResolvingStrategy, if they are a good addition to the general default behavior.
if the usecases are too exotic for the "mainstream" such an SPI makes sense.
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Thursday, November 3, 2016 9:51 AM
>To: Sling Developers
>Subject: [CAConfig] Provide an SPI for transformation of config refs
>
>Hi,
>
>the current mechanism (implemented in
>DefaultConfigurationResourceResolvingStrategy) uses the value from the
>sling:confRef property and validates it against some built-in rules.
>One of them is discarding relative paths.
>
>We would like to have a hook/SPI for allowing relative paths and for
>further validation like if the sling:confRef property contains the
>bucketName "sling:configs", the value should be discarded.
>
>So basically what I'm thinking of is an interface with a single method
>taking the ContextResource and the bucket name and returning a string
>(absolute path) or null.
>
>WDYT?
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org