Sorry, I forgot to mention that the Search Path Extension is prepended to the Search Path when it is requested (in the Resource Resolver).
- Andy On Feb 20, 2014, at 10:20 PM, Andreas Schaefer Sr. <[email protected]> wrote: > Hi > > I started to look into how to add tenant support to Sling. > > This is my test scenario: > > I have an /apps/foo/bar/html.esp and a /apps/tenant1/foo/bar/html.esp and a > /content/mynode entry. The title of the second html.esp is different so that > I know which one is loaded. > > Changes to the code: > > 1) Added get/setSearchPathExtension() to the Resource Resolver and its > implementation. > > 2) In the SlingRequestProcessorImpl I extract the tenant from the first sub > domain (no OSGi Service yet) and prepend it with /apps/ to the Search Path > Extension > > 3) In the Servlet Resolver added the code to set the Search Path Extension > from the Resource’s Resource Resolver onto the Script Resource Resolver. > > Ran it and it showed the Tenant Specific ESP when the host name has a tenant > it as sub domain and the original ESP when used with localhost. > > This shows that is it basically possible to thread through the tenant Search > Path on a per-call basis to the Servlet Resolver. There is still much to do > like the Cache handling in the Servlet Resolver and a OSGi service that > provides the tenant from a request. > > I can create an Issue and add a patch of my changes to it if anyone is > interested. > > Cheers - Andy > > On Feb 17, 2014, at 6:58 PM, Andreas Schaefer Sr. <[email protected]> wrote: > >> Hi >> >> I am working for a client which needs support for tenants and because the >> current implementation of the Tenants in Sling is just that but no >> integration I started to code a workaround. For now I have a patch that does >> the trick but it is not clean because I use a Servlet Filter to place the >> tenant id on a thread local instance. Afterwards I started to look into how >> to implemented this cleanly into the current version of Sling. >> >> There are a few areas that need to be changed in order to implement tenant >> support. For now I am only looking into how to implement a “per-call >> overlays of servlets / JSPs” in order to give tenants the chance to change >> aspects of their presentation. >> >> 1) Tenant Identification: Sling must be able to identify a tenant. This can >> be a sub domain, path, cookies or even parameters. This means the client >> needs to provide a service which is then used by Sling in order to retrieve >> the tenant and provide it to whomever wants to use it. >> >> 2) Servlet Resolver needs to be changed twofolds >> a) Being able to extend the search path for Servlets / JSPs based on >> the tenant’s data >> b) Caching the Servlets / JPSs separated for different tenants >> >> 3) Change the Felix OSGi Web Plugin to allow the clients to add properties >> (single and multi values) >> >> >> For 1) I would suggest just to define an interface the client can implement >> as an OSGi service which is used to identify a tenant. Then somewhere in the >> SlingMainServlet or the Request Data the Tenant is retrieved set on the >> Sling Http Servlet Request and if applicable the Search Path of the Resource >> Resolver is “enhanced/extended”. >> >> For 2) I would suggest to add a new property to the Resource Resolver which >> contains the Search Path Extension. Because the Servlet Resolver uses the >> Administrative Resource Resolver we need a way to “Enhance the Search Path” >> for that particular call. This could be done with a one-off wrapper. Based >> on the Extended Search Path we can determine which Servlet is an overlay and >> cache the overlays separately. >> >> 3) should be straight forward. >> >> Carsten was suggesting something like a TenantProvider like the >> ServletProvider but in the current code the ServletProvider is called with >> either the Sling Servlet Request, the Resource or a Resource Resolver and >> path. This means the tenant id must be available to any of these calls which >> would require to put the tenant id inside the Resource Resolver. >> >> Let me know what you think. >> >> - Andy Schaefer >> >
