We should not return fake resources from a service which are not available using the same path (the resource returns) via the resoruce resolver. Assume, you get a resource from the service, do a getParent() what resource does it return, especially if that doesn't exist? Or even if that resource exists in the resource tree, you get back a "real" resource, do a listChildren and the resource returned by the service is not in this list. Finally, this mechanism bypasses all other Sling mechanisms like resource decorators, the access security gate, feature flags (and there might be more).
If you provide a generic service which gets a mount path, search paths etc. as parameters, this is open to any value. First allowing all values, and then checking them within the service and potentially rejecting values does not seem like a good idea. For example, what if the client passes in /libs/bla, the current resource resolver has no access to this resource and therefore it can be used as it is a non existing path? There are all kinds of problems. Maybe if you describe your exact use case, it would help to understand why you need this. Regards Carsten 2014-03-03 23:23 GMT+01:00 Alexander Klimetschek <[email protected]>: > On 02.03.2014, at 23:05, Carsten Ziegeler <[email protected]> wrote: > > > public MergeData merge(String[] paths) > > But why not make it implement Resource then (as it already does)? > > > Having a method which gets a relative path together with the search paths > > The concept of "root path" plus "relative path" plus "list of merge paths" > is generic. The relative path logic can be very different from the one used > for the search paths today (this might the cause of some confusion). > > Cheers, > Alex -- Carsten Ziegeler [email protected]
