[ https://issues.apache.org/jira/browse/SLING-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved SLING-2739. ------------------------------------- Resolution: Fixed > Add methods for handling the resource type hierarchy to the resource resolver > ----------------------------------------------------------------------------- > > Key: SLING-2739 > URL: https://issues.apache.org/jira/browse/SLING-2739 > Project: Sling > Issue Type: Task > Components: API, ResourceResolver, Servlets > Reporter: Carsten Ziegeler > Assignee: Carsten Ziegeler > Fix For: Servlets Resolver 2.2.2, JCR Resource 2.2.6, File System > Resource Provider 1.1.2, Extensions Bundleresource 2.1.2, API 2.3.2, JCR > Jackrabbit User Manager 2.2.2, Resource Resolver 1.0.6 > > > 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 three methods to the resource resolver: > String getResourceSuperType(final Resource resource); > String getResourceSuperType(final String resourceType); > boolean isResourceType(final Resource resource, final String > resourceType); > Now, the corresponding three methods on ResourceUtil can be deprecated and > call the ResourceResolver methods instead. > The AbstractResource#isResourceType(String) method can be changed to call the > method on the ResourceResolver as well > With this we have a central implementation at a convenient place. We remove > the workaround from the servlet resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira