searchPath based on content path + multitenancy

[Henry Saginor <hs...@gmail.com>]

Hi,

I have a need to execute different scripts for my resource types based on content resource path.
For example resources under /content/abc and /content/xyz have the same resource types but should be rendered differently.  
I was reading [1] and [2] which seem to describe how this can be implemented via multi tenancy.
But I don’t think this has been integrated into script resolution process yet. What is the current state of this and what’s the plan? 

I can work on a patch. But I would need some guidance to make sure it is constant with the Sling vision for multitenancy.

Are there any other ideas on how to do this? Currently my application has a customized Servlet Resolver that does this. 
But this makes upgrades more difficult because application code is coupled with a specific version of servlet resolver. So, we have to port our code every time we need to upgrade Servlet Resolver.

[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases <https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases>

Regards,

Henry

Re: searchPath based on content path + multitenancy

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> On Thu, Mar 3, 2016 at 8:26 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I was thinking of rewriting the whole script resolution mechanism to
>> have a better caching mechanism. Maybe if we do one of these things we
>> look into the other as well :)..
> 
> I think so - including some form of "context key" in the cache keys
> makes multiple resolution contexts possible, so rewriting with this
> new use case in mind should help.
> 
Today, the cache is totally sub optimal as it does not take the
available scripts into account, but it uses the input from the request
(resource types, extensions, selectors) as a key. And therefore the
cache blows up with extensive selector usage.
We need to change that and build keys based on the available scripts
(and therefore selectors that are handled). This reduces the key space
for cache keys and makes the cache way more efficient, regardless if
users use selectors to pass parameters or not.
I think this shouldn't be too hard to do, but it requires some changes
and at the same time we should also rethink other things like handling
the resource type hierarchy etc.
I was planning to write RTs about those two topics in the near future,
still need some time to properly write it down :(

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: searchPath based on content path + multitenancy

[Bertrand Delacretaz <bd...@apache.org>]

On Thu, Mar 3, 2016 at 8:26 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I was thinking of rewriting the whole script resolution mechanism to
> have a better caching mechanism. Maybe if we do one of these things we
> look into the other as well :)..

I think so - including some form of "context key" in the cache keys
makes multiple resolution contexts possible, so rewriting with this
new use case in mind should help.

-Bertrand

Re: searchPath based on content path + multitenancy

[Carsten Ziegeler <cz...@apache.org>]

Henry Saginor wrote
> Thanks Bertrand,
> I see that at Sling engine level ServletResolver is pluggable already. So, this is something I could do at the project level as well. 
> Project level ServletResolver could still delegate to default SlingServletResolver, I suppose, after resolving script name to absolute path or wrapping SlingHttpServletRequest (depending on the method called). 
> Since true multitanancy has much bigger scope than what I need and is still experimental I think I will investigate this route.
> 
> What do you think of exposing a more general purpose extension point in default SlingServletResolver so it can delegate actual script path resolution to a service interface? Technically multetenancy could be plugged in using the same general purpose interface.
> 
I'm not completely against such a thing, however we need to take care
that we can describe a stable system, which means I guess you don't want
to have your servlet resolver available without your required extension.
In addition, and even more important, we have to think about caching of
the script resolution. In fact, script resolution is one of the slowest
parts in Sling as it is very very flexible and without caching it's
basically not usable.
I was thinking of rewriting the whole script resolution mechanism to
have a better caching mechanism. Maybe if we do one of these things we
look into the other as well :)

 Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: searchPath based on content path + multitenancy

[Henry Saginor <hs...@gmail.com>]

Thanks Bertrand,
I see that at Sling engine level ServletResolver is pluggable already. So, this is something I could do at the project level as well. 
Project level ServletResolver could still delegate to default SlingServletResolver, I suppose, after resolving script name to absolute path or wrapping SlingHttpServletRequest (depending on the method called). 
Since true multitanancy has much bigger scope than what I need and is still experimental I think I will investigate this route.

What do you think of exposing a more general purpose extension point in default SlingServletResolver so it can delegate actual script path resolution to a service interface? Technically multetenancy could be plugged in using the same general purpose interface.

Henry

> On Mar 2, 2016, at 1:33 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 
> Hi,
> 
> On Tue, Mar 1, 2016 at 11:06 PM, Henry Saginor
> <hs...@gmail.com> wrote:
>> ...Currently my application has a customized Servlet Resolver that does this...
> 
> If you're adventurous you could have a look at my content-based
> dynamic search path prototype at [1], that does something similar
> IIUC.
> 
> At the Sling engine level this requires a fairly small change to the
> SlingServletResolver to use a MultitenantServletResolver - it might be
> possible to add an extension point to make such things pluggable, if
> there are solid use cases behind that.
> 
> Note that I haven't run that code in a while, not sure if it still
> works in its current form.
> 
> -Bertrand
> 
> [1] https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model
> 
> [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/multisling2015/

Re: searchPath based on content path + multitenancy

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Tue, Mar 1, 2016 at 11:06 PM, Henry Saginor
<hs...@gmail.com> wrote:
> ...Currently my application has a customized Servlet Resolver that does this...

If you're adventurous you could have a look at my content-based
dynamic search path prototype at [1], that does something similar
IIUC.

At the Sling engine level this requires a fairly small change to the
SlingServletResolver to use a MultitenantServletResolver - it might be
possible to add an extension point to make such things pluggable, if
there are solid use cases behind that.

Note that I haven't run that code in a while, not sure if it still
works in its current form.

-Bertrand

[1] https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model

[2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/multisling2015/

Re: searchPath based on content path + multitenancy

[Henry Saginor <hs...@gmail.com>]

Hi Jorg,

Thank you for your input. I have considered using different resource types. This would work.
But my use case is a bit different from true multi-tenancy. This is one company/tenant hosting their own Sling (CQ just upgraded to AEM 6.1) instances. 
They have been working on reimplementing components to be “responsive”. As requirements changed the new responsive content also had to be re-authored. 
But while not all pages exist yet under responsive tree we have to be able to render old content using legacy components. 
And yes we could still run some scripts to change resource types under responsive tree. 
But eventually we will throw away old components and would like to keep the project structure the same (main reason for the same resource types). So, we would need to run scripts again to change resource types back.
I just found patching servlet resolver easer. It has worked well for us and we can just throw it away later. The only issue like I said is upgrading. This was intended as temp solution until we migrate the site completely. 
But content re-authoring is taking longer than originally assumed and we have to keep supporting both responsive and legacy content. 

I can still re-patch newer servlet resolver when we need to upgrade. It’s not a huge problem. But I wanted to look into implementing something more general that I could give back open source community and Tenant API seemed ideal.

Henry

> On Mar 2, 2016, at 12:53 AM, Jörg Hoh <jh...@googlemail.com> wrote:
> 
> Hi Henry,
> 
> we had the same challenge, and instead of changing/patching the resource
> resolver we change the resource types. So each tenant has its own
> resourcetype namespace; for example
> /apps/tenannts/components/page/homepage. So we can use the "defaults" here,
> and just provide different renderings.
> 
> Jörg
> 
> 
> 2016-03-01 23:06 GMT+01:00 Henry Saginor <hs...@gmail.com>:
> 
>> Hi,
>> 
>> I have a need to execute different scripts for my resource types based on
>> content resource path.
>> For example resources under /content/abc and /content/xyz have the same
>> resource types but should be rendered differently.
>> I was reading [1] and [2] which seem to describe how this can be
>> implemented via multi tenancy.
>> But I don’t think this has been integrated into script resolution process
>> yet. What is the current state of this and what’s the plan?
>> 
>> I can work on a patch. But I would need some guidance to make sure it is
>> constant with the Sling vision for multitenancy.
>> 
>> Are there any other ideas on how to do this? Currently my application has
>> a customized Servlet Resolver that does this.
>> But this makes upgrades more difficult because application code is coupled
>> with a specific version of servlet resolver. So, we have to port our code
>> every time we need to upgrade Servlet Resolver.
>> 
>> [1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
>> [2]
>> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
>> <
>> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
>>> 
>> 
>> Regards,
>> 
>> Henry
> 
> 
> 
> 
> -- 
> Cheers,
> Jörg Hoh,
> 
> http://cqdump.wordpress.com
> Twitter: @joerghoh

Re: searchPath based on content path + multitenancy

[Jörg Hoh <jh...@googlemail.com>]

Hi Henry,

we had the same challenge, and instead of changing/patching the resource
resolver we change the resource types. So each tenant has its own
resourcetype namespace; for example
/apps/tenannts/components/page/homepage. So we can use the "defaults" here,
and just provide different renderings.

Jörg


2016-03-01 23:06 GMT+01:00 Henry Saginor <hs...@gmail.com>:

> Hi,
>
> I have a need to execute different scripts for my resource types based on
> content resource path.
> For example resources under /content/abc and /content/xyz have the same
> resource types but should be rendered differently.
> I was reading [1] and [2] which seem to describe how this can be
> implemented via multi tenancy.
> But I don’t think this has been integrated into script resolution process
> yet. What is the current state of this and what’s the plan?
>
> I can work on a patch. But I would need some guidance to make sure it is
> constant with the Sling vision for multitenancy.
>
> Are there any other ideas on how to do this? Currently my application has
> a customized Servlet Resolver that does this.
> But this makes upgrades more difficult because application code is coupled
> with a specific version of servlet resolver. So, we have to port our code
> every time we need to upgrade Servlet Resolver.
>
> [1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
> [2]
> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
> <
> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
> >
>
> Regards,
>
> Henry




-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh