Hi, Tobias Bocanegra schrieb: > On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegeler<cziege...@apache.org> > wrote: >> Hi, >> >> while changing the script resolution in the last days a little bit to >> make it cacheable, I stumbled across the handling of the resource super >> type. >> The jcr resource implementation checks if the node has the >> sling:resourceSuperType property and returns this value if existent. >> If not, it tries to find a resource under the search paths (usually libs >> and apps) with the resource type converted to a path. So if a resource >> has the type "a/b", the resources /apps/a/b and /libs/a/b are tested if >> they exist and contain a resource super type property. >> >> Other resource implementations like the bundle resource always returns >> null. The fs resource implemenations returns a special resource type for >> the resource super type. >> >> I think this behaviour is a little bit inconsistent. I would change it >> that if a resource does not know it's super type, it should return null. >> So basically this effects the implementation of the jcr resource. >> The script resolver already checks if the resource super type is null >> and then applies the above algoritm from the jcr resource as well. >> >> Otherwise each resource implemenation should apply the algorithm to be >> consistent. But I would prefer the first solution. >> >> While the change is incompatible, I think this doesn't have any real effect. > > i agree that the resource should not know about search paths. imo, the > resource resolver should be used for 'resolving' the resource super > type.
Actually, the ResourceResolver *is* used to resolve the super type from a resource type resource: // resource type rel path, e.g. nt/file String path = resourceTypeToPath(resourceType); // resolve resource type resource Resource rtResource = resourceResolver.getResource(path); The getResource method applies the current search path as described and required and requested. Regards Felix
