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 > my current usecases are: > - having the ability to inject context objects like request in any sling > model, regardless of the adaptable. this is e.g. importing when adapting from > a resource, but in context of a request (SLING-4083) That should be possible to solve differently, such injection sounds like too much magic to me. Why can't sling models have a clear API that passes in such objects when they are created instead of going through a threadlocal? > - configuration parameter override provider which injects overrides from HTTP > header for test environments [4] This shows that wcm.io is doing too much magic... also, what do you mean by test environments? That seems very specific, not sure if that validates such a change in the main sling api. > [5] http://sling.markmail.org/thread/epn5vdw3fkmpsk6w Those use cases fall under the "have to use ThreadLocal because we can't change the API", so IMO don't warrant to put that into Sling API, it should be hidden in those modules that need to do the ThreadLocal workaround for their integration. Citing Bertrand from that thread: "Passing the request to a method clearly indicates that you expect that method to deal with it. It's a few more characters to type, but it makes things clear. IMHO, it's too easy to create a mess with threadlocals, which are just another kind of global variables." Cheers, Alex
