Hi Andy, I'm not sure if we need search path extensions which are not related to tenants. The adaption to a tenant does not tie it to the resource resolver module, the adapter factory can live in the tenant module and therefore the resource resolver module is totally unaware of tenant handling. The adaption can internally use a thread local which holds the tenant from the request, so even for administrative resource resolvers, an adaptTo would work within the context of a request.
But these are just rough ideas anyway :) Regards Carsten 2014-02-21 17:16 GMT+01:00 Andreas Schaefer Sr. <schaef...@me.com>: > Hi Carsten > > First I want to clarify that the Search Path Extension has nothing to do > with Tenants per se but is a "per-call" extension of the search path which > could be used without tenants.In order to make the overlays work the Search > Path Extension must be set early on. For this part the client could > implement a Service or configure a Service to obtain the Search Path > Extension. > > Currently I have a working POC for a client using CQ 5.6.1 which uses this > concept to having Servlets/JSP overlays but also tenant specific > translation (I18n) both working through the Search Path Extension. > > The TenantResolver is an good idea but the > ResourceResolver.adaptTo(Tenant.class) might be a problem due to the > Administrative Resource Resolver (Servlet Resolver) and also ties Tenants > into the Resource Resolver module. > > - Andy > > On Feb 20, 2014, at 11:32 PM, Carsten Ziegeler <cziege...@apache.org> > wrote: > > > Hi Andy, > > > > this sounds interesting - and I guess a patch would be great. Now I just > > would like to present my idea again - just for the sake of discussion :) > > > > I think over time there will be more components than just the servlet > > resolver which make use of the tenant and the extended search path, so I > > think it would be great to have some generic mechanism to get the > "current" > > tenant. > > My first idea was to have a TenantAware interface which passes in a > > TenantResolver (bad name) instance. And whenever the tenant aware > component > > needs the current tenant it asks the resolver, maybe a method like > > Tenant getTenant(ResourceResolver resolver) > > We could then extend the Tenant interface to provide the extended search > > path. > > > > This would keep all the tenant extension stuff out of the resource > resolver > > - and would just be an extension. > > > > Instead of using a TenantResolver we could go with > > ResourceResolver.adaptTo(Tenant.class) > > > > WDYT? > > > > Carsten > > > > > > 2014-02-21 7:53 GMT+01:00 Andreas Schaefer Sr. <schaef...@me.com>: > > > >> 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. <schaef...@me.com> > >> 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. <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 > >>>> > >>> > >> > >> > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
