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
