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 this method always returns the same value. If we would change that, we would break a lot of code - and the tenant discussion actually made me aware of it :) Regards Carsten 2014-02-25 19:07 GMT+01:00 Andreas Schaefer Sr. <schaef...@me.com>: > 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 > > On Feb 25, 2014, at 12:20 AM, Felix Meschberger <fmesc...@adobe.com> > wrote: > > > Hi > > > > Am 25.02.2014 um 07:43 schrieb Carsten Ziegeler <cziege...@apache.org>: > > > >> 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 it's pretty clear that > clients > >> assume its static. Many components read this value once and then go > with it. > >> > >> Therefore I would like to update the javadocs and add a remark that this > >> value never changes for a single resource resolver. > >> > >> Makes sense? > > > > I agree. Yet, maybe you might want to add this, too: Two distinct > ResourceResolver instances created by the same ResourceResolverFactory need > not have the same search path. [ I am sure you find better wording ;-) ] > > > > Regards > > Felix > > > > > > -- Carsten Ziegeler cziege...@apache.org
