Those are good examples. So if it's made robust and part of sling, maybe. But I wouldn't suggest it to client side application developers building website components. Keep it simple and "stupid".
Sarwar On Mon, May 14, 2012 at 5:33 PM, Chetan Mehrotra <[email protected]>wrote: > > 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 > > >
