If you want the method to get the search paths extensions to be on the resource resolver and make it independent of a tenant, then why do we need this method at all? In the case of a tenant getSearchPath would return the normal search path with the tenant specific one prepended.
Carsten 2014-02-24 18:43 GMT+01:00 Andreas Schaefer Sr. <[email protected]>: > Hi Carsten > > Even if a Search Path Extension is not used outside of the Tenants I still > think it would be great to keep things separate. Based on my tests if the > Search Path Extension is set when the Resource Resolver of a request is > created and the Servlet resolver's own Resource Resolver is temporary > extended with the same Search Path Extension we can provide a tenant > specific view with multiple tenants. > > Even though I like the idea of a Tenant Adapter Factory I don't think this > works out. Tenants are not only used for logged in users but also for the > public view and the resource path is limited as well because what if the > tenant viewer is requesting a common page (landing page etc) but the tenant > provided some customization on the imported sub pages (ESPs, JSPs and > Servlets) through overlays. > > If a Thread Local is ok and we could make the Search Path Extension on the > Resource Resolver settable then we could use a Request Servlet Filter to > extract the Tenant from the Request using a Service which the host can > override to resolve the Tenant and then set the Search Path Extension. From > there on the Servlet Resolver does not need to know if this is a Tenant > because the Search Path Extension of the Request or Resource is enough to > provide tenant specific view. > > Cheers - Andy > > On Feb 21, 2014, at 10:06 AM, Carsten Ziegeler <[email protected]> > wrote: > > > 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. <[email protected]>: > > > >> 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 <[email protected]> > >> 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. <[email protected]>: > >>> > >>>> 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 > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Carsten Ziegeler > >>> [email protected] > >> > >> > > > > > > -- > > Carsten Ziegeler > > [email protected] > > -- Carsten Ziegeler [email protected]
