You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2013/02/22 10:16:13 UTC

[jira] [Commented] (SLING-2739) Add methods for handling the resource type hierarchy to the resource resolver

    [ https://issues.apache.org/jira/browse/SLING-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584109#comment-13584109 ] 

Carsten Ziegeler commented on SLING-2739:
-----------------------------------------

I've committed a first implemented as outlined above in revision 1448950.

I'll leave this open for further discussions
                
> 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