Am 22.10.14 um 23:21 schrieb Alexander Klimetschek: > On 22.10.2014, at 01:22, Stefan Seifert <sseif...@pro-vision.de> wrote: >> i propose to add a new feature to the Sling API and Sling Engine to access >> to the current request via an OSGi service, using a servlet filter and a >> thread local internally. > > -1 > >> a proposal for such an implementation is currently part of sling models >> trunk, but should be renamed and moved to a more central part if we agree if >> it is a good idea. interface [1], impl [2]. > > Why? This looks like a hack to me, and will lead to people not designing > their APIs properly (e.g. passing the request through). I see ThreadLocal as > a workaround when you don't have influence on the API but still need to pass > things around. But in this case (sling models and the wcm.io config, below) > there is full control over the API. > > A class like SlingObjectInjectorRequestContext sound very much like > anti-patterns from Spring et al. > >> we have already a comparable threadlocal concept for resource resolver [3] > > Broken window :D
Well, it's easy to judge on a high level without knowing the details. We're all aware of the dangers of thread locals, but matter of fact is, there are use cases where you need the resource resolver and there are tons of layers in between the code using the resource resolver and where it is available. In some cases the api is not even created in Sling, so there is absolutely no way to pass the resolver down to the code other than using a thread local. And instead of creating an island solution for every use case, so we end up with dozens of thread locals and filters and whatnot, having a general single solution is imho preferable. However, I see/have use cases for the resource resolver, I'm not 100% about the request yet :) Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
