2013/2/21 Felix Meschberger <[email protected]>: > Hi Carsten > > Thanks for taking this issue up. It has been nagging us for too long ;-) > > I agree, that we should handle this "centrally" with an administrative > resource resolver. So maybe the "obvious" solution is really to do it in the > ResourceResolver itself. We should thus deprecate the ResourceUtil.isA method > while the Resource.isResourceType method should stay (is easy to use if you > already have the Resource) but should this be implemented with the new method. > > Why getEffectiveSuperType instead if getSuperType ?
I thought to distinguish it from the getSuperType method of the Resource which does not go up the hierarchy. Carsten > > Regards > Felix > > Am 21.02.2013 um 13:49 schrieb Carsten Ziegeler: > >> Hi, >> >> looking again at SLING-2708, I think we have a fundamental >> misconception in the way we treat the resource type hierarchy. This >> affects the isA check and the detection of the effective resource >> super type by looking at the resource tree. >> In early Sling versions we used the current resource resolver >> (session) in the implementation of those functions, but as soon as the >> resource resolver did not have read access to the search paths in the >> resource tree, these checks failed. After hitting this problem, we >> implemented the isA check by implementing a resource decorator in the >> Sling Servlet Resolver (SLING-2693). The idea was to use the same user >> as we use to resolve scripts. With SLING-2708 we hit another area >> where this problem occurs. >> >> Now, looking back, I think the solution of SLING-2693 is wrong - the >> resource type hierarchy has nothing to do with execution rights and is >> completely independent from executing scripts. >> >> I think we should rather add two methods to the resource resolver: >> isA(Resource, String) and getEffectiveSuperType(Resource) - these >> methods will be implemented by the resource resolver and use a session >> which has read access to the whole tree (it could also cache the >> hierarchy if required). >> With this we have a central implementation at a convenient place. We >> remove the workaround from the servlet resolver and point all current >> methods (ResourceUtil and AbstractResource) to the ResourceResolver. >> >> WDYT? >> Carsten >> -- >> Carsten Ziegeler >> [email protected] > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > -- Carsten Ziegeler [email protected]
