Hi everyone, didn't follow the whole discussion so I might have missed some poin but if I get it right the case where it gets problematic is when I essentially want to adapt to from a resource (that is not the currentResource) without losing the request scope.
While request.adaptTo(Target.class) would enable an AdapterFactory to get hold of the currentResource there is no chance to get the the custom resource. To get around that I was thinking if it wouldn't be a good idea to add a further adaptTo() signature which would allow to add a generic payload which could contain contextobjects that an adapterFactory could use for construction.In case of SlingModels everything in this payload could be injected if there is a matching property to inject those. I know its a bold idea but much less magic then ThreadLocals. Cheers Dominik On Thu, Oct 23, 2014 at 8:22 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > 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 >
