Hi Julian
Am 12.11.2012 um 10:33 schrieb Julian Sedding:
> Hi Amit
>
> Thanks for taking a stab at multi-tenancy support. I have looked at
> your patch and I re-read Felix' draft spec on the wiki[0].
>
> The code and the spec leave me with some thoughts. Sorry for the
> lengthy reply, the thoughts are still pretty fresh in my mind.
>
> The spec states that multi-tenancy support is targeted to a hosted
> scenario, where several Sling applications (let's simplify to
> websites) run side by side.
Yes, that was an initial though. But running different applications for
different tenants is a tricky thing because the Java platform does not allow
use to properly sandbox those applications and thus to prevent on application
from starving another application.
For now, only the TenantProvider/Tenant part is implemented and we did not
consider the tenant-specific ResourceResolution yet.
> I think this can easily be extended to
> cases where a large corporation runs websites of several brands on the
> same Sling instance. Assuming our brands are "banana", "kiwi" and
> "lemon", we'd have a content structure like this:
>
> "tenants": {
> "banana": { ... },
> "kiwi": { ... },
> "lemon": { ... }
> }
>
> The main purpose of multi-tenancy support (as per my interpretation of
> the spec) is to be able to use different rendering scripts for
> different tenants, which is expressed via the concept of the
> ResourceResolver(Factory)#searchPath.
>
> Assuming we want the "banana" and "lemon" websites to be rendered with
> the "yellow" application and the "kiwi" website with the "green"
> application (and assuming we don't use CSS for this...), we might want
> our rendering scripts organized like this:
>
> "apps": {
> "yellow": { ... },
> "green": { ... },
> "shared": { ... }
> }
>
> As far as I can see, the currently committed code doesn't enhance the
> search paths yet. However, it looks like it is intended that tenants
> get resolved mapped from the paths of any of the following:
> * user home path (e.g. /home/users/banana/julian; this is kind of CQ
> specific, afaik jackrabbit still uses the system workspace for users
> by default, so there's no /home/users)
> * resource path (e.g. /tenants/kiwi)
>
> So if I request the page /tenants/kiwi logged in as julian, I could
> get two different resolutions, depending on whether the implementation
> adapts the Resource (/tenants/kiwi), which leads to the tenant "green"
> or the ResourceResolver backed by the user julian, which leads to the
> tenant "yellow".
I think if you are logged in, you are being run under the hood of the tenant to
which you as the logged in user belong. So in your case, the tenant would be
"green".
As a member of the "green" tenant you might not even have access the kiwi tree.
In which case, there is no reason to assume the request resource path to be the
tenant to consider.
As a consequence, I agree, that the anonymous user by itself is not running
under the hood of a tenant.
>
> Considering that most requests to websites are "anonymous", I suggest
> that multi-tenancy support should only care about the resource being
> requested, not about the requesting user, This also guarantees
> consistent results for rendering.
This (and the following) raise good questions. And we are not ready to answer
them (yet) and we are not even considering per-tenant applications (for above
stated reasons).
So we left out tenant-awareness of the ResourceResolver by intent.
>
> Looking at the problem from this angle, script resolution (i.e.
> looking up the resource type relative path) needs depend on the
> location of the requested resource. This in turn rules out the
> possibility to adapt a ResourceResolver to a tenant, because the RR
> does not have a path. Also setting injecting the search path into the
> RR is troublesome, because /tenants/kiwi might include resources from
> /tenants/banana by reference and would thus need to trigger the
> "yellow" rendering for these includes (or are there arguments against
> this?).
>
> Given the above thoughts, I would allow adapting a Resource to a
> Tenant. The Tenant would correspond to the Resource itself or to an
> ancestor of the Resource (i.e. hierarchical inheritance). Since the
> tenant would thus correspond to a Resource, maybe it makes sense to
> have the Tenant interface extend from Resource. If no Tenants are
> configured, the attempt to adapt a Resource to a tenant may return
> null or a default Tenant, which is rooted at the resource tree's root
> (maybe this would simplify implementations).
Even though a Tenant may correspond a Resource (which is wrong, because at best
a Resource corresponds to a Tenant) this does not imply a Tenant is a Resource.
Because this is an implementation detail of implementing the Tenant interface.
The Tenant interface is just representing a concept of a collection of users
sharing some common setup.
>
> All of this raises the question of the consistency of search paths, as
> the ResourceResolver cannot convey tenant specific search paths,
> however the script resolution would need to depend upon tenant
> specific search paths. To me it seems that multi-tenancy support might
> require the extension of some sling concepts. This extension could
> (and should IMHO) be implemented as a hook, which allows to manipulate
> script resolution. Having such a hook should decouple the
> multi-tenancy implementation from the core of sling and possibly allow
> for alternative implementations.
That's another reason why we won't go for tenant-aware script resolution yet.
This whole thing cannot and should not be simply backed into the existing
implementations. Your stated reasons are one part of this, another part is
bloating the existing implementations and making them more complex.
The current idea is just:
* A ResourceResolver representing a user (just like JCR Session does) can be
adapted to a Tenant to which the user "belongs".
* A Resource can be adapted to a Tenant under the assumption that the
respective Resource belongs to one of the Tenant's data areas in the repository.
Hope this helps.
Regards
Felix
>
> WDYT?
>
> Regards
> Julian
>
> [0] https://cwiki.apache.org/SLING/multitenancy-support.html
>
>
> On Mon, Nov 12, 2012 at 3:35 AM, Amit.. Gupta. <[email protected]> wrote:
>> Thanks Felix.
>>
>> I will work on the web console plugin.
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:[email protected]]
>> Sent: 10 November 2012 04:23
>> To: [email protected]
>> Subject: Re: Multi-tenancy support in Sling - SLING-2656
>>
>> Hi Amit
>>
>> Thanks alot. I have applied your patch with some changes (see SLING-2656 for
>> details). I placed it as th extensions/tenant module in the contrib section
>> for now. As of now it only provides the Tenant API but no integration with
>> the rest in Sling. As such it is of use mainly to multi-tenancy aware uses.
>>
>> I think we should just provide read access through the TenantProvider and
>> leave management (create, update, delete) to some administrative tooling;
>> e.g. a web console plugin.
>>
>> I also removed the default configuration which does not relate to Sling.
>>
>> Would you be able to come up with a Web Console Plugin for management ?
>>
>> Regards
>> Felix
>>
>> Am 08.11.2012 um 11:03 schrieb Amit.. Gupta.:
>>
>>> Hi All,
>>>
>>> I have created an issue [0] to track support for multi-tenancy in sling.
>>>
>>> I have also added a first cut implementation that provides basic building
>>> blocks [1]
>>>
>>> [1] provides following
>>>
>>> * Tenant and TenantProvider abstraction at sling
>>>
>>> * Basic JCR based TenantProvider
>>>
>>> * An adapter factory to adapt resourceResolver to tenant, based on
>>> logged in user
>>>
>>> TODO:
>>>
>>> * externalize the logic of identifying tenant based on logged in
>>> User.
>>>
>>> * Add support to resolve resource to a tenant, for use cases where
>>> there is no logged in user and execution is happening in some admin
>>> context. i.e. observation listener.
>>>
>>> With above basic support, we can later add support for new Tenant Aware
>>> JcrResourceResolver.
>>>
>>> Please comment on the patch/issue.
>>>
>>> Thanks,
>>> Amit
>>> [0] https://issues.apache.org/jira/browse/SLING-2656
>>> [1] https://github.com/amitxlnc/sling/compare/mt
>>>
>>>
>>>
>>>
>>
