On Tue, Dec 14, 2010 at 2:07 AM, Unmesh Joshi <[email protected]> wrote:
> Hi, > > I observed that when some resource is not found. (In my case, browser > was sending request for favicon.ico), JcrResourceResolver iterates > through all the resource providers, loads resources and then tries to > match sling:alias property. > I have a custom resource provider which has to make a web service call > to build resource. So ends up making unnecessary service calls for > favicon.ico. I do not even know what the original request is > (favicon.ico), because I always get > same path for which the resource provider is registered. I managed > to add a guard clause somehow, but I do not think its clean. > There was an issue raised about this on the dev list last month with respect to user/group management. I think the outcome is that it this is a known issue. However, it should be only touching ResourceProviders at the same "level" as the resource being requested, so a simple suggestion would be to register your custom ResourceProvider at a sub-path, not the top level > > So a couple of questions. > > 1. What is difference between resource resolver and resource provider? > The big difference is that a particular Sling instance should have exactly one implementation of ResourceResolverFactory whereas there can be any number of ResourceProvider services. In essence, the ResourceResolverFactory is what makes the entire resource tree available to the application whereas ResourceProviders allow for the resource tree to be composed of multiple sources. > Is it recommended to implement custom resource resolver? Any samples? > AFAIK, there is no publicly available ResourceResolverFactory other than the JCR one. > 2. Can sling:alias behavior be turned off? > I don't think so, but you could check the source to be sure. I think a better solution would be to have ResourceProviders somehow able to say "don't ask me about sling:alias", but I haven't thought that through. Justin > > Thanks, > Unmesh >
