Henry Saginor wrote > Thanks Bertrand, > I see that at Sling engine level ServletResolver is pluggable already. So, > this is something I could do at the project level as well. > Project level ServletResolver could still delegate to default > SlingServletResolver, I suppose, after resolving script name to absolute path > or wrapping SlingHttpServletRequest (depending on the method called). > Since true multitanancy has much bigger scope than what I need and is still > experimental I think I will investigate this route. > > What do you think of exposing a more general purpose extension point in > default SlingServletResolver so it can delegate actual script path resolution > to a service interface? Technically multetenancy could be plugged in using > the same general purpose interface. > I'm not completely against such a thing, however we need to take care that we can describe a stable system, which means I guess you don't want to have your servlet resolver available without your required extension. In addition, and even more important, we have to think about caching of the script resolution. In fact, script resolution is one of the slowest parts in Sling as it is very very flexible and without caching it's basically not usable. I was thinking of rewriting the whole script resolution mechanism to have a better caching mechanism. Maybe if we do one of these things we look into the other as well :)
Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
