[
https://issues.apache.org/jira/browse/SLING-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-2739:
------------------------------------
Fix Version/s: JCR Jackrabbit User Manager 2.2.2
Extensions Bundleresource 2.1.2
File System Resource Provider 1.1.2
JCR Resource 2.2.6
> 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
