On 03.03.2014, at 23:05, Carsten Ziegeler <cziege...@apache.org> wrote:
> We should not return fake resources from a service which are not available > using the same path (the resource returns) via the resoruce resolver. If it's provided by a resource provider, that will be the case. Although I don't think it's a big issue. The resource tree implicitly provided by the service is consistent. Maybe we should just make it clear that you should normally not use the ResourceMergerService directly, but only inside a ResourceProvider. And application code would only use it via the mounted provider, say /mnt/overlay, never directly. The service is not intended to be an alternative to the resource resolver, in no way. > Assume, you get a resource from the service, do a getParent() what resource > does it return, especially if that doesn't exist? This should be clearly defined by the merging logic. > 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. The design was (when I discussed it with Gilles) to always return a merged resource and never a real one directly. In order to handle proper tree traversal (with everything merged properly, including children and ancestors) this is a strict requirement anyway IIRC. > Finally, this mechanism bypasses all other Sling mechanisms like resource > decorators, the access security gate, feature flags (and there might be > more). Yes (if you just look at the merger; and this is perfectly fine, I don't see why you want to mix different concerns here), no (if it is used via resource provider). > 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. You would of course only use it properly. The same argument can be made for ResourceProviders etc. - I can implement them by using an admin resource resolver and thus exposing the entire existing tree. That doesn't make sense either. > Maybe if you describe your exact use case, it would help to understand why > you need this. I think I explained it enough in this thread and before. It's about extending or overlaying things by specifying a delta/patch, not by copying content. This is a generic principle that can be done on the resource level instead of implementing it again and again for different application cases. This concept is not restricted to the sling search path. Cheers, Alex
