Hi was going through the how sling resolution works.
I came against this scenario which is mentioned on Adobe aem-developer guide
https://docs.adobe.com/docs/en/aem/6-2/develop/the-basics.html
This is the scenario which is mentioned- / a ( does not have any resource supertype or resource type)
b (sling:resourceSuperType = a)
c (sling:resourceSuperType = b)
x (sling:resourceType = c)
y (sling:resourceType = c, sling:resourceSuperType = a)
The type hierarchy of /x is [ c, b, a, ] while for /y the hierarchy is [ c, a, ] because /y has the sling:resourceSuperType property whereas /x does not and therefore its supertype is taken from its resource type.
now I understand how /x is resolved. But I am not sure about /y. first it resolved to /c. which itself had an sling:resourceSuperType as b. Should the sling resolution not go to /b as well. how is the supertype is overriden and resource is resolved to a instead of b.
As explained in the Apache Sling documentation, if a sling:resourceSuperType is defined for a particular resource, it will be used. If it's not present, the framework will use the sling:resourceSuperType defined by the resource pointed to by the sling:resourceType.
That said, in case of /y, /b will not be treated as a super type. The sling:resourceSuperType defined by /y itself points directly to /a. It will effectively hide the sling:resourceSuperType property defined at /c (and pointing at /b) that would otherwise be taken into account.
The example is quite well described on the very documentation page you linked to.
In my experience, most custom AEM components are easier to maintain if the resource type hierarchy is defined by a set of nodes defining a component and present in the repository as descendants of /apps or /libs (when including OOTB components in the inheritance hierarchy). Specific instances of components (including ones responsible for rendering whole Pages) present in the /content sub-tree can then unambiguously define a sling:resourceType that determines its type (inheritance or not). Personally, I prefer not to define the sling:superResourceType at the level of a resource that's part of the /content sub-tree as it makes the hierarchy somewhat more difficult to reason about. Off the top of my head, I can't think of a use case that would justify this trade-off. Perhaps someone else could weigh in if they know a good one.