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