Hi all
I missed the discussion where the InheritableThreadLocal behaviour was
reverted. We actually have several places in our application where we
wish to kick off tasks to run in a background thread with the
permissions of the user who started them. InheritableThreadLocal did the
job, but I see it's been reverted (although there's no mention in the
current upgrade notes, and the existing upgrade notes for 0.9.0 are
plain wrong).
Since this seems like a useful thing to want to do, and since the error
was caused by a bug in a single platform only in debug mode, reverting
the entire behaviour seems a bit heavy handed. I would like to propose
that InheritableThreadLocal gets put back with an option to turn it off,
in some user-configurable way. There are several ways to do it, although
the obvious one is using a system property. Thus the existing code which
looks like this:
private static ThreadLocal contextHolder = new ThreadLocal();
would instead look something like this:
private static ThreadLocal contextHolder;
static {
String prop =
System.getProperty("org.acegisecurity.context.SecurityContextHolder.UseI
nheritableThreadLocal");
boolean useInheritable = prop != null ? new
Boolean(prop).booleanValue() : true; // default to true
contextHolder = useInheritable ? new
InheritableThreadLocal() : new ThreadLocal();
}
The user could then define the system property appropriately. I don't
know how easy it is to do such thing in WebSphere (the buggy platform),
though. There are other approaches:
- If the bug is one in IBM's JDK, we could look for known buggy jdk
versions in the system properties "java.vm.version" and
"java.vm.vendor". That would stop websphere devs from being able to run
the default when they run in non-debug mode (which apparently isn't
buggy), but it's no change to the existing behaviour for them and a
marked improvement for everyone using non-buggy jdks.
- We could look for a given resource using e.g.
System.getResourceAsStream("org/acegisecurity/context/SecurityContextHol
der.properties") and look for a specific property.
- I see that Oliver Hutchison sent a proposal after the code was
reverted suggesting a strategy interface which didn't get any replies; I
think that idea is also good and would allow configuration using spring
but default to InheritableThreadLocal. It needn't even be as heavy as
Oliver's solution: Simply having a static setThreadLocalImpl(ThreadLocal
tl) would do the trick, and would be reasonably guaranteed to be called
before any user iteraction if done inside a spring config file.
If none of the above are acceptable, then perhaps a utility method to
start a new thread with inherited contexts would be appropriate,
something like (untested):
public static void runWithCurrentContext(final Runnable r) {
final SecurityContext ctx =
SecurityContextHolder.getContext();
Runnable r2 = new Runnable() {
public void run() {
SecurityContextHolder.setContext(ctx);
r.run();
}
}
new Thread(r).start();
}
I can do this in our application code just for our case (and will have
to in the meantime), but that only solves the problem in a straight out
start-this-thread kind of scenario. If you're using something like the
executors in JDK 1.5's java.util.concurrent, you don't always have a
handle on the thread that's going to run. In any case, having to
explicitly do this stuff in code which shouldn't have to know about
security is exceedingly ugly IMO.
Anyway, I'd be interested to hear people's thoughts.
Cheers
Tom
************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.
************************************************************************
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
