> aarghh ;-) I knew it is coming .... :) I understand that threadlocals are dangerous but they do have there uses in infrastructure components like in Security context , Transaction context propagation.
Couple of examples where I feel they help 1. I had to implement a Client SDK for a remote server in Sling. The usecase involved flow like Http Request -> Sling Servlet -> OSGi Service Proxy -> Outpbound RPC call over Web Service. In such a scenario I had pass in the invoking user identity. For this I need to access the ResourceResolver associated with current thread and extract the user identity from the associated JCR session 2. Using RequestprogressTracker as poor man profiler - I like the RequestProgressTracker feature of Sling and would like to use it to capture time taken in some of the lower layers of my system. For example in scenario mentioned earlier I would like to keep a log of the time taken for the remote RPC call however that layer does not have access to request instance Probably the usecases I have dealt with might not be generic but having the current request's ResourceResolver available via ThreadLocal helps in write some infrastructure components!! Chetan Mehrotra On Mon, May 14, 2012 at 7:37 PM, Bertrand Delacretaz <[email protected] > wrote: > On Mon, May 14, 2012 at 2:55 PM, Chetan Mehrotra > <[email protected]> wrote: > > ...It would be helpful if we can expose the current > SlingHttpServletRequest or > > ResourceResolver via a threadlocal... > > aarghh ;-) > > > ..This would simplify code where we need > > pass the request as method parameters . This can be done via a simple > > FIlter which publishes the request into a thread local and have a new API > > class which makes this request accessible.... > > This would work, but I would be against including such a filter in the > Sling codebase. > > 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. > > -Bertrand >
