2013/2/21 Tyson Norris <[email protected]>: > > > 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 [email protected]
