>If we think that inheritance is used sparsely then I think e) is the
>best option - at least it is easy to understand. If you want to have
>inheritance all over the place, it means that you have to set the
>correct property all over the place. But then, this is still the
>approach with less magic
Stefan Seifert wrote
>> Lets assume we have
>> /conf/global/set/a
>> /conf/project/set/b
>> /conf/project/foo/set/c
>>
>> and the context resource points to /conf/project/foo and you want all
>> children of "set", then I assume the inherit property is only changed on
>> /conf/project/foo/set. If th
>Lets assume we have
>/conf/global/set/a
>/conf/project/set/b
>/conf/project/foo/set/c
>
>and the context resource points to /conf/project/foo and you want all
>children of "set", then I assume the inherit property is only changed on
>/conf/project/foo/set. If that is false, nothing happens.
>If it
Stefan Seifert wrote
> one thought i had when implementing SLING-6059 and SLING-6058 (resource and
> property inheritance):
>
> - currently both inheritance variants are switched off by default
> - they can be switched on by setting a special inherit property in the
> configuration resource
> -
My experience is that looking up the ancestors of a node for property
inheritance does indeed have a significant performance impact.
My experience was in the realm of:
https://docs.adobe.com/docs/en/cq/5-6-1/developing/cloud-service-configurations.html
https://docs.adobe.com/docs/en/cq/5-6-1/java
one thought i had when implementing SLING-6059 and SLING-6058 (resource and
property inheritance):
- currently both inheritance variants are switched off by default
- they can be switched on by setting a special inherit property in the
configuration resource
- this property can either be set on
