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