Hi, Am 21.02.2013 um 15:43 schrieb Carsten Ziegeler:
> 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. What hierarchy ? ResourceUtil.getSuperType(Resource) first asks the resource for a super type and then falls back to ResourceUtil.getResourceSuperType(ResourceResolver, String) which uses the resource type as a resource and checks that. But yes, the JcrNodeResource does not do this. We should maybe fix this by calling ResourceUtil.getResourceSuperType(ResourceResolver, String) if there is no super type property ? Or maybe something else ? In fact, looking at the ResourceUtil.getSuperType(Resource) method, this should be changed to call into the new ResourceResolver method which in turn gets back to the ResourceUtil.getResourceSuperType(ResourceResolver, String) with the admin resolver. Regards Felix > > 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] -- Felix Meschberger | Principal Scientist | Adobe
