Just to recap to see if I got this right: - TenantAware is an OSGi service that a client can implement to identify a tenant (if applicable) based on a request
- A Servlet Filter is taking the request, obtains the TenantAware service and calls a method like "setup(SlingHttpServletRequest)” to initialize the Tenant Resolver - The Authentication Service as well as the Servlet Resolver is using the TenantResolver to adjust the Search Path when creating / using a Resource Resolver or Resource Resolver must be made aware of the Tenant and adjust their search path when there is a Tenant. Do you have any other implementation that works like that so that I can better understand where you are coming from. For me the most important question is if you indent to move the Tenant code into the bundles or if you want it to keep it in the contrib part. For the latter we cannot use the Tenant class anywhere in the modules of the bundles. - Andy On Feb 25, 2014, at 12:55 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > I think using a thread local is an implementation detail and TenantAware > has a single method like > > TenantResolver getTenantResolver() > > while TenantResolver has a single method > > Tenant getCurrentTenant() > > (Don't quote me on the names, its just the first option which came to my > mind) > > And then either Tenant gets a method returning the additional search path, > or we use a convention, like /libs/{tenantId} and /apps/{tenantId} > > The implementation of the tenant resolver would use a thread local > > Carsten > > > 2014-02-25 19:18 GMT+01:00 Andreas Schaefer Sr. <schaef...@me.com>: > >> Ok, will adjust the wiki page. >> >> - Andy >> >> On Feb 25, 2014, at 1:11 AM, Bertrand Delacretaz <bdelacre...@apache.org> >> wrote: >> >>> On Tue, Feb 25, 2014 at 2:41 AM, Andreas Schaefer Sr. <schaef...@me.com> >> wrote: >>>> ...it might a good idea to add the getSearchPathExtension() to the >> Tenant... >>> >>> Shouldn't that rather be called getAdditionalSearchPaths? >>> >>> In Sling, "extension" means the .html at the end of a URL, IMO we >>> should avoid reusing that term for other things, as much as possible. >>> >>> -Bertrand >> >> > > > -- > Carsten Ziegeler > cziege...@apache.org