I think that would call for a set of implementation which will talk to the ThreadLocal context, e.g. ExecutorService.submit() would look at the store and attach the current context to the work being submitted and restore it when a thread picks up the work... It should not be hard to create such a decorator.
toggle quoted messageShow quoted text
From: Ed Warnicke (eaw)
Sent: Friday, June 13, 2014 10:10 PM
Cc: Kent Watsen; Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco);
Nguyen, Liem Manh
Subject: Musings about passing SecurityContexts between threads
At the AAA meeting this week, as Liem was walking us through the
code, he showed us attaching security context to an InheritableThreadLocal
store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and
executors where you may pass work from one thread to another, but not by
spawning new threads. I had mused about that being worrisome to me,
because it requires folks to get it right at many many places in the code
every time work is passed between threads, but that I didn't have a smarter
idea, and that might be the state of what could be done. (which is to say, as
a matter of personal technical opinion I made mild grumbly noises, but
couldn't be constructive about helping to move things forward and so
appropriately didn't press it much past making my grumble known ;) ).
I still don't have a better way... but was curious if other folks had any
thoughts/experience to share as to other options and the tradeoffs in