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 ? 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 > cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe
