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 <[email protected]>: > 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 [email protected]
