No, I don't think it does limit the Tenant implementation - at least as
long as we provide an additional way of providing the per tenant search
path than using getSearchPath of the resource resolver.
It's a fact that code in Sling and also in the code of client code using
Sling is assuming that th
This feels wrong to me. Not that it does not reflect the current state of
things but rather because it maybe limiting the tenant implementation.
I am still working through Sling to understand it inner workings because most
of what I know is based on CQ and not on using Sling directly.
- Andy
O
Got point, I've updated the javadocs in rev 1571670
Carsten
2014-02-25 9:20 GMT+01:00 Felix Meschberger :
> Hi
>
> Am 25.02.2014 um 07:43 schrieb Carsten Ziegeler :
>
> > Hi,
> >
> > while thinking about the tenant stuff (see separate thread), I (again)
> came
> > across the fact, that we
> > d
Hi
Am 25.02.2014 um 07:43 schrieb Carsten Ziegeler :
> Hi,
>
> while thinking about the tenant stuff (see separate thread), I (again) came
> across the fact, that we
> don't say anything whether ResourceResolver#getSearchPath is static or
> dynamic (if the value might change at runtime for the s
Hi,
while thinking about the tenant stuff (see separate thread), I (again) came
across the fact, that we
don't say anything whether ResourceResolver#getSearchPath is static or
dynamic (if the value might change at runtime for the same resource
resolver).
Looking at code using the resource resolver
