Hi Andy, Thank you for bringing this up. I have a similar requirement. I don’t see any way of integrating Tenants other than patching Servlet Resolver. This is what I had done for my customer but for a really specific case (they are not truly multi-tenant). I also had to use ThreadLocal. I didn’t really see a better approach because a request is not always available in servlet resolver. So, if you have to map your tenant id to any information in the request you have to. Please let me know if you can think of something better.
Also, for 1) I think beyond an interface you can provide some generic implementation and configuration factory. With configuration factory you can create and configure multiple instances with different configurations (sub-domain/path/cookies/parameters). With this I would say 3) is not a requirement unless I miss-undertood what you meant. Maybe you could open a JIRA ticket and post a patch there. Henry On Feb 17, 2014, at 6:58 PM, Andreas Schaefer Sr. <schaef...@me.com> 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 >
