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. Henry > On Mar 2, 2016, at 1:33 AM, Bertrand Delacretaz <[email protected]> > wrote: > > Hi, > > On Tue, Mar 1, 2016 at 11:06 PM, Henry Saginor > <[email protected]> wrote: >> ...Currently my application has a customized Servlet Resolver that does >> this... > > If you're adventurous you could have a look at my content-based > dynamic search path prototype at [1], that does something similar > IIUC. > > At the Sling engine level this requires a fairly small change to the > SlingServletResolver to use a MultitenantServletResolver - it might be > possible to add an extension point to make such things pluggable, if > there are solid use cases behind that. > > Note that I haven't run that code in a while, not sure if it still > works in its current form. > > -Bertrand > > [1] > https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model > > [2] > https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/multisling2015/
