You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Julian Sedding <js...@gmail.com> on 2013/02/11 09:14:59 UTC
Clarification of Resource#getResourceSuperType() contract
Hello all
I stumbled over a behavior in Resource#getResourceSuperType() that is
unexpected to me. I would like to clarify the contract of this method.
The JavaDoc for Resource#getResourceSuperType() states "Returns the
super type of the type of the resource or null if the
getResourceType() has no supertype.". I'll illustrate my understanding
of this contract with a simple example.
/content/resource [sling:resourceType="type"]
/apps/type [sling:resourceSuperType="super"]
/apps/super
Now if I have an instance of the Resource at /content/resource and
call ist getResourceSuperType() method, I'd expect to get the string
"super" as the return value ("the super type of the type of the
resource").
However, the JcrNodeResource[0], and possibly more importantly its
test cases[1] (specifically testResourceSuperType()), implement a
behavior that differs from my understanding of the documented
contract. In the above scenario,
JcrNodeResource#getResourceSuperType() would return null, while the
scenario below would yield "super".
/content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
/apps/type
/apps/super
To me the documented contract is more intuitive, as that is how
inheritance generally works in my experience (i.e. my grandmother can
only be my grandmother transiently via one of my parents). However,
I'm curious to see whether others have other opinions.
BTW, MongoDBResource#getResourceSuperType() seems to implement the
same contract that JcrNodeResource does. Additionally, also
ResourceUtil#findResourceSuperType() supports the logic implemented in
JcrNodeResource.
I noticed this while implementing a possible fix for SLING-2708, which
is concerned with the ResourceUtil#isA() and Resource#isResourceType()
methods. Depending on the implementation of those methods (whether
they rely on Resource#getResourceSuperType() or not), they may yield
different results.
Thank you for your comments.
Regards
Julian
[0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
[1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
Re: Clarification of Resource#getResourceSuperType() contract
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
> Given the current documentation of the Resource interface and the
> implementation of e.g. JcrNodeResource, I suggest that we document
> Resource#getResoureSuperType() as follows:
>
> [The method #getResoureSuperType()] Returns the value of the
> "sling:resourceSuperType" property of the current resource if
> available. Otherwise it returns the super type of the type of the
> resource (as per #getResourceType()) or null if the type has no super
> type.
>
> Does that sound reasonable?
This would us require to change the getResourceSuperType method of our
implementations to do
the lookup in the resource tree. So I think we should change the docs to state
that this method only returns a value if the "sling:resourceSuperType"
property is set.
Although this property might be implementation specific, so we need
some different wording :)
Looking back, I think adding the isResourceType method to the Resource
interface was wrong
as this is using information outside of the scope of the resource.
getResourceType and getResourceSuperType return the information from a
resource only
if the resource has this information.
If you want to get the (calculated) resource super type of a resource,
we have methods on ResourceUtil to do the trick.
(Although these don't work because the resource tree is read with the
resource resolver from the passed resource).
I have the feeling that we should clean up this area...
Carsten
>
> Regards
> Julian
>
>
> On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> 2013/2/11 Julian Sedding <js...@gmail.com>:
>>> When you say overriding, do you mean, it eliminates an inherited
>>> resource type, or is it squeezed in between? Example:
>>
>> It elimantes, so it's:
>>>
>>> Option A (eliminates inherited super-type): type, local-super, local-super-super
>>
>>>
>>> Surely there are more possible options, however, I think these are the
>>> most sensible ones. It might also be worthwhile considering, what
>>> happens if the two hierarchies join back on a common ancestor...
>>
>> The whole type hierarchy handling is on demand, so there are no checks
>> enforced, a wrongly setup type hierarchy could e.g. end up in an
>> endless loop etc.
>>
>>> I think we need to keep the override-mechanism due to backwards
>>> compatibility, so adjusting the JavaDocs seems sensible. However, I
>>> would like to document that a local sling:resourceSuperType property
>>> overrides the default behavior, which is the traversal of the
>>> inheritance-hierarchy (as is currently documented). In addition, if we
>>> decide for one of the above options, this should also be documented.
>> Which two options are you refering to? :)
>>
>> Regards
>> Carsten
>>
>>> This would allow using only the expected/intuitive case (i.e. not to
>>> use any local overrides). At the same time this should provide a
>>> backwards compatible solution.
>>>
>>> WDYT?
>>>
>>> Regards
>>> Julian
>>>
>>>
>>> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>> Hi,
>>>>
>>>> I agree we have a mismatch here. The way we usually handle
>>>> getResourceSuperType and how it is implemented is, that it returns a
>>>> super type information only if the resource by itself has set this
>>>> (for example for a jcr node if it has the property). The method does
>>>> not evaluate the resource hierarchy.
>>>> As far as I remember (this dates really long way back...) the idea is,
>>>> that a resource can either specify a super type by itself - using this
>>>> method or if it doesn't, the super type is evaluated using the type
>>>> hierarchy from the resource tree. This allows for overriding the
>>>> resource super type on a per resource base.
>>>>
>>>> However, I agree that this is a little bit unexpected - so I think we
>>>> should update the javadocs of the Resource interface to reflect
>>>> realitity.
>>>> We could add a method to get the real super type like we have for the isA check.
>>>>
>>>> WDYT?
>>>>
>>>> Carsten
>>>>
>>>> 2013/2/11 Julian Sedding <js...@gmail.com>:
>>>>> Hello all
>>>>>
>>>>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>>>>> unexpected to me. I would like to clarify the contract of this method.
>>>>>
>>>>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>>>>> super type of the type of the resource or null if the
>>>>> getResourceType() has no supertype.". I'll illustrate my understanding
>>>>> of this contract with a simple example.
>>>>>
>>>>> /content/resource [sling:resourceType="type"]
>>>>> /apps/type [sling:resourceSuperType="super"]
>>>>> /apps/super
>>>>>
>>>>> Now if I have an instance of the Resource at /content/resource and
>>>>> call ist getResourceSuperType() method, I'd expect to get the string
>>>>> "super" as the return value ("the super type of the type of the
>>>>> resource").
>>>>>
>>>>> However, the JcrNodeResource[0], and possibly more importantly its
>>>>> test cases[1] (specifically testResourceSuperType()), implement a
>>>>> behavior that differs from my understanding of the documented
>>>>> contract. In the above scenario,
>>>>> JcrNodeResource#getResourceSuperType() would return null, while the
>>>>> scenario below would yield "super".
>>>>>
>>>>> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
>>>>> /apps/type
>>>>> /apps/super
>>>>>
>>>>> To me the documented contract is more intuitive, as that is how
>>>>> inheritance generally works in my experience (i.e. my grandmother can
>>>>> only be my grandmother transiently via one of my parents). However,
>>>>> I'm curious to see whether others have other opinions.
>>>>>
>>>>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>>>>> same contract that JcrNodeResource does. Additionally, also
>>>>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>>>>> JcrNodeResource.
>>>>>
>>>>> I noticed this while implementing a possible fix for SLING-2708, which
>>>>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>>>>> methods. Depending on the implementation of those methods (whether
>>>>> they rely on Resource#getResourceSuperType() or not), they may yield
>>>>> different results.
>>>>>
>>>>> Thank you for your comments.
>>>>>
>>>>> Regards
>>>>> Julian
>>>>>
>>>>>
>>>>> [0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
>>>>> [1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
>>>>
>>>>
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: Clarification of Resource#getResourceSuperType() contract
Posted by Julian Sedding <js...@gmail.com>.
Hi Carsten
Agreed, Option A resembles the currently implementation most closely.
This also ensures that there is only a single inheritance hierarchy
(or line of inheritance), so there won't be any problems.
Given the current documentation of the Resource interface and the
implementation of e.g. JcrNodeResource, I suggest that we document
Resource#getResoureSuperType() as follows:
[The method #getResoureSuperType()] Returns the value of the
"sling:resourceSuperType" property of the current resource if
available. Otherwise it returns the super type of the type of the
resource (as per #getResourceType()) or null if the type has no super
type.
Does that sound reasonable?
Regards
Julian
On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> 2013/2/11 Julian Sedding <js...@gmail.com>:
>> When you say overriding, do you mean, it eliminates an inherited
>> resource type, or is it squeezed in between? Example:
>
> It elimantes, so it's:
>>
>> Option A (eliminates inherited super-type): type, local-super, local-super-super
>
>>
>> Surely there are more possible options, however, I think these are the
>> most sensible ones. It might also be worthwhile considering, what
>> happens if the two hierarchies join back on a common ancestor...
>
> The whole type hierarchy handling is on demand, so there are no checks
> enforced, a wrongly setup type hierarchy could e.g. end up in an
> endless loop etc.
>
>> I think we need to keep the override-mechanism due to backwards
>> compatibility, so adjusting the JavaDocs seems sensible. However, I
>> would like to document that a local sling:resourceSuperType property
>> overrides the default behavior, which is the traversal of the
>> inheritance-hierarchy (as is currently documented). In addition, if we
>> decide for one of the above options, this should also be documented.
> Which two options are you refering to? :)
>
> Regards
> Carsten
>
>> This would allow using only the expected/intuitive case (i.e. not to
>> use any local overrides). At the same time this should provide a
>> backwards compatible solution.
>>
>> WDYT?
>>
>> Regards
>> Julian
>>
>>
>> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> Hi,
>>>
>>> I agree we have a mismatch here. The way we usually handle
>>> getResourceSuperType and how it is implemented is, that it returns a
>>> super type information only if the resource by itself has set this
>>> (for example for a jcr node if it has the property). The method does
>>> not evaluate the resource hierarchy.
>>> As far as I remember (this dates really long way back...) the idea is,
>>> that a resource can either specify a super type by itself - using this
>>> method or if it doesn't, the super type is evaluated using the type
>>> hierarchy from the resource tree. This allows for overriding the
>>> resource super type on a per resource base.
>>>
>>> However, I agree that this is a little bit unexpected - so I think we
>>> should update the javadocs of the Resource interface to reflect
>>> realitity.
>>> We could add a method to get the real super type like we have for the isA check.
>>>
>>> WDYT?
>>>
>>> Carsten
>>>
>>> 2013/2/11 Julian Sedding <js...@gmail.com>:
>>>> Hello all
>>>>
>>>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>>>> unexpected to me. I would like to clarify the contract of this method.
>>>>
>>>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>>>> super type of the type of the resource or null if the
>>>> getResourceType() has no supertype.". I'll illustrate my understanding
>>>> of this contract with a simple example.
>>>>
>>>> /content/resource [sling:resourceType="type"]
>>>> /apps/type [sling:resourceSuperType="super"]
>>>> /apps/super
>>>>
>>>> Now if I have an instance of the Resource at /content/resource and
>>>> call ist getResourceSuperType() method, I'd expect to get the string
>>>> "super" as the return value ("the super type of the type of the
>>>> resource").
>>>>
>>>> However, the JcrNodeResource[0], and possibly more importantly its
>>>> test cases[1] (specifically testResourceSuperType()), implement a
>>>> behavior that differs from my understanding of the documented
>>>> contract. In the above scenario,
>>>> JcrNodeResource#getResourceSuperType() would return null, while the
>>>> scenario below would yield "super".
>>>>
>>>> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
>>>> /apps/type
>>>> /apps/super
>>>>
>>>> To me the documented contract is more intuitive, as that is how
>>>> inheritance generally works in my experience (i.e. my grandmother can
>>>> only be my grandmother transiently via one of my parents). However,
>>>> I'm curious to see whether others have other opinions.
>>>>
>>>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>>>> same contract that JcrNodeResource does. Additionally, also
>>>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>>>> JcrNodeResource.
>>>>
>>>> I noticed this while implementing a possible fix for SLING-2708, which
>>>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>>>> methods. Depending on the implementation of those methods (whether
>>>> they rely on Resource#getResourceSuperType() or not), they may yield
>>>> different results.
>>>>
>>>> Thank you for your comments.
>>>>
>>>> Regards
>>>> Julian
>>>>
>>>>
>>>> [0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
>>>> [1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Clarification of Resource#getResourceSuperType() contract
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
2013/2/11 Julian Sedding <js...@gmail.com>:
> When you say overriding, do you mean, it eliminates an inherited
> resource type, or is it squeezed in between? Example:
It elimantes, so it's:
>
> Option A (eliminates inherited super-type): type, local-super, local-super-super
>
> Surely there are more possible options, however, I think these are the
> most sensible ones. It might also be worthwhile considering, what
> happens if the two hierarchies join back on a common ancestor...
The whole type hierarchy handling is on demand, so there are no checks
enforced, a wrongly setup type hierarchy could e.g. end up in an
endless loop etc.
> I think we need to keep the override-mechanism due to backwards
> compatibility, so adjusting the JavaDocs seems sensible. However, I
> would like to document that a local sling:resourceSuperType property
> overrides the default behavior, which is the traversal of the
> inheritance-hierarchy (as is currently documented). In addition, if we
> decide for one of the above options, this should also be documented.
Which two options are you refering to? :)
Regards
Carsten
> This would allow using only the expected/intuitive case (i.e. not to
> use any local overrides). At the same time this should provide a
> backwards compatible solution.
>
> WDYT?
>
> Regards
> Julian
>
>
> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> I agree we have a mismatch here. The way we usually handle
>> getResourceSuperType and how it is implemented is, that it returns a
>> super type information only if the resource by itself has set this
>> (for example for a jcr node if it has the property). The method does
>> not evaluate the resource hierarchy.
>> As far as I remember (this dates really long way back...) the idea is,
>> that a resource can either specify a super type by itself - using this
>> method or if it doesn't, the super type is evaluated using the type
>> hierarchy from the resource tree. This allows for overriding the
>> resource super type on a per resource base.
>>
>> However, I agree that this is a little bit unexpected - so I think we
>> should update the javadocs of the Resource interface to reflect
>> realitity.
>> We could add a method to get the real super type like we have for the isA check.
>>
>> WDYT?
>>
>> Carsten
>>
>> 2013/2/11 Julian Sedding <js...@gmail.com>:
>>> Hello all
>>>
>>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>>> unexpected to me. I would like to clarify the contract of this method.
>>>
>>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>>> super type of the type of the resource or null if the
>>> getResourceType() has no supertype.". I'll illustrate my understanding
>>> of this contract with a simple example.
>>>
>>> /content/resource [sling:resourceType="type"]
>>> /apps/type [sling:resourceSuperType="super"]
>>> /apps/super
>>>
>>> Now if I have an instance of the Resource at /content/resource and
>>> call ist getResourceSuperType() method, I'd expect to get the string
>>> "super" as the return value ("the super type of the type of the
>>> resource").
>>>
>>> However, the JcrNodeResource[0], and possibly more importantly its
>>> test cases[1] (specifically testResourceSuperType()), implement a
>>> behavior that differs from my understanding of the documented
>>> contract. In the above scenario,
>>> JcrNodeResource#getResourceSuperType() would return null, while the
>>> scenario below would yield "super".
>>>
>>> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
>>> /apps/type
>>> /apps/super
>>>
>>> To me the documented contract is more intuitive, as that is how
>>> inheritance generally works in my experience (i.e. my grandmother can
>>> only be my grandmother transiently via one of my parents). However,
>>> I'm curious to see whether others have other opinions.
>>>
>>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>>> same contract that JcrNodeResource does. Additionally, also
>>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>>> JcrNodeResource.
>>>
>>> I noticed this while implementing a possible fix for SLING-2708, which
>>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>>> methods. Depending on the implementation of those methods (whether
>>> they rely on Resource#getResourceSuperType() or not), they may yield
>>> different results.
>>>
>>> Thank you for your comments.
>>>
>>> Regards
>>> Julian
>>>
>>>
>>> [0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
>>> [1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: Clarification of Resource#getResourceSuperType() contract
Posted by Julian Sedding <js...@gmail.com>.
Hi Carsten
Thanks for your comments.
> This allows for overriding the
> resource super type on a per resource base.
When you say overriding, do you mean, it eliminates an inherited
resource type, or is it squeezed in between? Example:
/content/resource [sling:resourceType="type",
sling:resourceSuperType="local-super"]
/apps/type [sling:resourceSuperType="inherited-super"]
/apps/local-super [sling:resourceSuperType="local-super-super"]
/apps/inherited-super [sling:resourceSuperType="inherited-super-super"]
Which would be the "correct" inheritance hierarchy in this example?
Option A (eliminates inherited super-type): type, local-super, local-super-super
Option B (injects local super-type) : type, local-super,
inherited-super, inherited-super-super
Option C (injects local-super-type hierarchy: type, local-super,
local-super-super, inherited-super, inherited-super-super
Surely there are more possible options, however, I think these are the
most sensible ones. It might also be worthwhile considering, what
happens if the two hierarchies join back on a common ancestor...
> However, I agree that this is a little bit unexpected - so I think we
> should update the javadocs of the Resource interface to reflect
> realitity.
> We could add a method to get the real super type like we have for the isA check.
I think we need to keep the override-mechanism due to backwards
compatibility, so adjusting the JavaDocs seems sensible. However, I
would like to document that a local sling:resourceSuperType property
overrides the default behavior, which is the traversal of the
inheritance-hierarchy (as is currently documented). In addition, if we
decide for one of the above options, this should also be documented.
This would allow using only the expected/intuitive case (i.e. not to
use any local overrides). At the same time this should provide a
backwards compatible solution.
WDYT?
Regards
Julian
On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I agree we have a mismatch here. The way we usually handle
> getResourceSuperType and how it is implemented is, that it returns a
> super type information only if the resource by itself has set this
> (for example for a jcr node if it has the property). The method does
> not evaluate the resource hierarchy.
> As far as I remember (this dates really long way back...) the idea is,
> that a resource can either specify a super type by itself - using this
> method or if it doesn't, the super type is evaluated using the type
> hierarchy from the resource tree. This allows for overriding the
> resource super type on a per resource base.
>
> However, I agree that this is a little bit unexpected - so I think we
> should update the javadocs of the Resource interface to reflect
> realitity.
> We could add a method to get the real super type like we have for the isA check.
>
> WDYT?
>
> Carsten
>
> 2013/2/11 Julian Sedding <js...@gmail.com>:
>> Hello all
>>
>> I stumbled over a behavior in Resource#getResourceSuperType() that is
>> unexpected to me. I would like to clarify the contract of this method.
>>
>> The JavaDoc for Resource#getResourceSuperType() states "Returns the
>> super type of the type of the resource or null if the
>> getResourceType() has no supertype.". I'll illustrate my understanding
>> of this contract with a simple example.
>>
>> /content/resource [sling:resourceType="type"]
>> /apps/type [sling:resourceSuperType="super"]
>> /apps/super
>>
>> Now if I have an instance of the Resource at /content/resource and
>> call ist getResourceSuperType() method, I'd expect to get the string
>> "super" as the return value ("the super type of the type of the
>> resource").
>>
>> However, the JcrNodeResource[0], and possibly more importantly its
>> test cases[1] (specifically testResourceSuperType()), implement a
>> behavior that differs from my understanding of the documented
>> contract. In the above scenario,
>> JcrNodeResource#getResourceSuperType() would return null, while the
>> scenario below would yield "super".
>>
>> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
>> /apps/type
>> /apps/super
>>
>> To me the documented contract is more intuitive, as that is how
>> inheritance generally works in my experience (i.e. my grandmother can
>> only be my grandmother transiently via one of my parents). However,
>> I'm curious to see whether others have other opinions.
>>
>> BTW, MongoDBResource#getResourceSuperType() seems to implement the
>> same contract that JcrNodeResource does. Additionally, also
>> ResourceUtil#findResourceSuperType() supports the logic implemented in
>> JcrNodeResource.
>>
>> I noticed this while implementing a possible fix for SLING-2708, which
>> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
>> methods. Depending on the implementation of those methods (whether
>> they rely on Resource#getResourceSuperType() or not), they may yield
>> different results.
>>
>> Thank you for your comments.
>>
>> Regards
>> Julian
>>
>>
>> [0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
>> [1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Clarification of Resource#getResourceSuperType() contract
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I agree we have a mismatch here. The way we usually handle
getResourceSuperType and how it is implemented is, that it returns a
super type information only if the resource by itself has set this
(for example for a jcr node if it has the property). The method does
not evaluate the resource hierarchy.
As far as I remember (this dates really long way back...) the idea is,
that a resource can either specify a super type by itself - using this
method or if it doesn't, the super type is evaluated using the type
hierarchy from the resource tree. This allows for overriding the
resource super type on a per resource base.
However, I agree that this is a little bit unexpected - so I think we
should update the javadocs of the Resource interface to reflect
realitity.
We could add a method to get the real super type like we have for the isA check.
WDYT?
Carsten
2013/2/11 Julian Sedding <js...@gmail.com>:
> Hello all
>
> I stumbled over a behavior in Resource#getResourceSuperType() that is
> unexpected to me. I would like to clarify the contract of this method.
>
> The JavaDoc for Resource#getResourceSuperType() states "Returns the
> super type of the type of the resource or null if the
> getResourceType() has no supertype.". I'll illustrate my understanding
> of this contract with a simple example.
>
> /content/resource [sling:resourceType="type"]
> /apps/type [sling:resourceSuperType="super"]
> /apps/super
>
> Now if I have an instance of the Resource at /content/resource and
> call ist getResourceSuperType() method, I'd expect to get the string
> "super" as the return value ("the super type of the type of the
> resource").
>
> However, the JcrNodeResource[0], and possibly more importantly its
> test cases[1] (specifically testResourceSuperType()), implement a
> behavior that differs from my understanding of the documented
> contract. In the above scenario,
> JcrNodeResource#getResourceSuperType() would return null, while the
> scenario below would yield "super".
>
> /content/resource [sling:resourceType="type", sling:resourceSuperType="super"]
> /apps/type
> /apps/super
>
> To me the documented contract is more intuitive, as that is how
> inheritance generally works in my experience (i.e. my grandmother can
> only be my grandmother transiently via one of my parents). However,
> I'm curious to see whether others have other opinions.
>
> BTW, MongoDBResource#getResourceSuperType() seems to implement the
> same contract that JcrNodeResource does. Additionally, also
> ResourceUtil#findResourceSuperType() supports the logic implemented in
> JcrNodeResource.
>
> I noticed this while implementing a possible fix for SLING-2708, which
> is concerned with the ResourceUtil#isA() and Resource#isResourceType()
> methods. Depending on the implementation of those methods (whether
> they rely on Resource#getResourceSuperType() or not), they may yield
> different results.
>
> Thank you for your comments.
>
> Regards
> Julian
>
>
> [0] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java
> [1] http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java
--
Carsten Ziegeler
cziegeler@apache.org