The support for workspaces has been dropped some time ago.
When it comes to multi tenancy, JCR already provides a good separation as
you have ACLs, therefore for pure content you can easily control the access
via ACLs.
The problem you might be hitting is, that you want to have different
rendering scripts so basically you want to have different content within
/apps /or /libs) based on the tenant. I guess this could be done using a
custom resource provider which does the dispatching, so if a script at
/apps/a/b/c is requested it serves it from
/tenant-scripts/{currentTenant}/a/b/c - which is a script in the repository
propertly ACL'ed. That's just a rough idea from the top of my head. But I
guess even with that, you might run into problems. For example, the script
resolution is currently cached - which wouldn't work in that case and needs
to be disabled.
But I guess the first question to answer is on what level you need
multi-tenancy - just content works ootb, scripting might be doable with a
resonable effort, application code (bundles) is a different beast.
Regards
Carsten
2014-07-30 9:08 GMT+02:00 Bertrand Delacretaz <[email protected]>:
> Hi,
>
> On Wednesday, July 30, 2014, anjan <[email protected]> wrote:
>
> > ...What is the
> > complexity (with respect to code changes) involved if the current Sling
> > instance has to support multiple Jackrabbit repositories?...
>
> I suspect doing that would unveil lots of subtle issues that are hidden now
> as we've been working with a single repository (and even single JCR
> workspace) all the time.
>
> Support for multiple JCR workspaces was added a while ago (you should be
> able to find relevant info in jira) but I'm not sure if anyone is currently
> using it.
>
> Another idea about multitenancy would be to have a kind of chroot
> functionality at the JCR repository level, where a given Sling instance
> would see /multi/instanceN as / at the JCR level. I have no idea how easy
> or hard that would be to implement at the Oak level, but if that's possible
> that would make such things easier.
>
> That's more questions than answers I guess - if others have concrete
> experience or feedback that would be welcome.
>
> -Bertrand
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
