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 <cz...@apache.org> on 2013/02/21 13:49:32 UTC
[RT] Accessing the resource type hierarchy
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
cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/2/21 Tyson Norris <tn...@adobe.com>:
>
>
> On a related note (IMHO), we ran into a separate irritating problem with
> SlingServletResolver where the wrapped resource becomes "untestable" using
> ResourceUtil.isA() AFTER a call to adaptTo(), because the wrapper
> delegates to the original resource whose resolver has no access to the
> types. (see SLING-2708)
>
> I think that:
> - adding ResourceResolver.isResourceType()
> - replacing some usages of ResourceUtil.isA() with
> ResourceResolver.isResourceType()
> Would fix this.
Yes, that bug exactly made me think about it again :)
>
> I would prefer Resource.getResourceSuperType() return null when the
> property is not set.
> I am trying to think of use cases that would get the super type, other
> than script resolution (internal to sling), or cases that are testing for
> type ancestry (which should ONLY use ResourceResolver.isResourceType()),
> so not sure where this comes up in an application use case?
The use cases should be rare - i've seen people doing checks against
the super type,
but they always use ResourceUtil .
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Ian Boston <ie...@tfd.co.uk>.
On 22 February 2013 20:20, Carsten Ziegeler <cz...@apache.org>
>
> What about naming the method getParentResourceType() ?
>
I'm good with that.
Thanks
Ian
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/2/21 Ian Boston <ie...@tfd.co.uk>:
> On 22 February 2013 02:25, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> The final question is the first point in this mail - do we leave the
>> implementations of Resource#getResourceSuperType() as is (= returning
>> null if they don't know it) or do we change that to call the
>> ResourceResolver#getResourceSuperType?
>
> Yes please, leave as is returning null.
Yes, I think that's the better option - I'll clarify the javadocs. For
example, the jcr resource tests explicitely test this behaviour.
>
> BTW, I thing the getEffectiveSuperType is good as it communicates the
> result is not the same as the property. Better might be to think of
> the results in terms of inheritance and give real isolation between
> the concepts. Newbees are going to find this area confusing (and I
> might have just proved myself to be a newbee). What about
> getInheritedType or allow for future expansion with
> String[] getInheritedTypes(Resource resource)
>
I wouldn't go the string array way unless we have a real good reason for this.
So far the use cases I know are either getting the direct super type
(for script resolution)
or checking if a resource is of some type.
What about naming the method getParentResourceType() ?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Ian Boston <ie...@tfd.co.uk>.
On 22 February 2013 02:25, Carsten Ziegeler <cz...@apache.org> wrote:
>
> The final question is the first point in this mail - do we leave the
> implementations of Resource#getResourceSuperType() as is (= returning
> null if they don't know it) or do we change that to call the
> ResourceResolver#getResourceSuperType?
Yes please, leave as is returning null.
I can think of many situations where I have checked that method
expecting it yo be the property and not wanting to bind to the Node
interface (because the resource might not be a Node).
BTW, I thing the getEffectiveSuperType is good as it communicates the
result is not the same as the property. Better might be to think of
the results in terms of inheritance and give real isolation between
the concepts. Newbees are going to find this area confusing (and I
might have just proved myself to be a newbee). What about
getInheritedType or allow for future expansion with
String[] getInheritedTypes(Resource resource)
?
Ian
In the first case, we need to
> clarify our docs, in the second we need to change the impls (and
> clarify the docs)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Tyson Norris <tn...@adobe.com>.
On 2/21/13 7:25 AM, "Carsten Ziegeler" <cz...@apache.org> wrote:
>2013/2/21 Felix Meschberger <fm...@adobe.com>:
>>
>> 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 ?
>
>I think we changed this some time ago to exactly not do this - can't
>remember why. So the current behaviour should be
>Resource#getResourceSuperType only returns a value if the resource by
>itself knows the super type (for jcr resources this means if it has
>this property). I'm not sure if we should change this.
>
>>
>> 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.
>
>Yes, while implementing this :) I just noticed that we need three
>methods on the ResourceResolver (notice I now name the method
>getResourceSuperType :) ):
> String getResourceSuperType(final Resource resource);
> String getResourceSuperType(final String resourceType);
> boolean isResourceType(final Resource resource, final String
>resourceType);
On a related note (IMHO), we ran into a separate irritating problem with
SlingServletResolver where the wrapped resource becomes "untestable" using
ResourceUtil.isA() AFTER a call to adaptTo(), because the wrapper
delegates to the original resource whose resolver has no access to the
types. (see SLING-2708)
I think that:
- adding ResourceResolver.isResourceType()
- replacing some usages of ResourceUtil.isA() with
ResourceResolver.isResourceType()
Would fix this.
So +1 to these changes :)
>
>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
>
>The final question is the first point in this mail - do we leave the
>implementations of Resource#getResourceSuperType() as is (= returning
>null if they don't know it) or do we change that to call the
>ResourceResolver#getResourceSuperType? In the first case, we need to
>clarify our docs, in the second we need to change the impls (and
>clarify the docs)
I would prefer Resource.getResourceSuperType() return null when the
property is not set.
I am trying to think of use cases that would get the super type, other
than script resolution (internal to sling), or cases that are testing for
type ancestry (which should ONLY use ResourceResolver.isResourceType()),
so not sure where this comes up in an application use case?
Thanks
Tyson
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/2/21 Felix Meschberger <fm...@adobe.com>:
>
> 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 ?
I think we changed this some time ago to exactly not do this - can't
remember why. So the current behaviour should be
Resource#getResourceSuperType only returns a value if the resource by
itself knows the super type (for jcr resources this means if it has
this property). I'm not sure if we should change this.
>
> 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.
Yes, while implementing this :) I just noticed that we need three
methods on the ResourceResolver (notice I now name the method
getResourceSuperType :) ):
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
The final question is the first point in this mail - do we leave the
implementations of Resource#getResourceSuperType() as is (= returning
null if they don't know it) or do we change that to call the
ResourceResolver#getResourceSuperType? In the first case, we need to
clarify our docs, in the second we need to change the impls (and
clarify the docs)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 21.02.2013 um 15:43 schrieb Carsten Ziegeler:
> 2013/2/21 Felix Meschberger <fm...@adobe.com>:
>> 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
>>> cziegeler@apache.org
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Accessing the resource type hierarchy
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/2/21 Felix Meschberger <fm...@adobe.com>:
> 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.
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
>> cziegeler@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Accessing the resource type hierarchy
Posted by Felix Meschberger <fm...@adobe.com>.
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
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Accessing the resource type hierarchy
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 21.02.2013, at 13:49, Carsten Ziegeler <cz...@apache.org> wrote:
> 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).
Big +1
Cheers,
Alex