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. 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".
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.
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).
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.
WDYT?
Regards
Julian
[0] https://cwiki.apache.org/SLING/multitenancy-support.html
On Mon, Nov 12, 2012 at 3:35 AM, Amit.. Gupta. <amitg...@adobe.com> wrote:
> Thanks Felix.
>
> I will work on the web console plugin.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: 10 November 2012 04:23
> To: users@sling.apache.org
> 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
>>
>>
>>
>>
>
