> I'd prefer to avoid multiple releases floating around. We
> should revert back to a standard ThreadLocal and not an
> InheritableThreadLocal and release 0.9.0. Does anyone really
> require InheritableThreadLocal behaviour?
I'm guessing this it's probably too late but what about providing a
SecurityContextHoldingStrategy? You could then provide an ITL, plain TL
and even thread global (useful for rich clients) holder implementations.
interface SecurityContextHoldingStrategy {
void setContext(SecurityContext context);
SecurityContext getContext();
}
public class ThreadLocalSecurityContextHoldingStrategy implements
SecurityContextHoldingStrategy {
private final ThreadLocal contextHolder;
public ThreadLocalSecurityContextHoldingStrategy() {
this(new ThreadLocal());
}
protected ThreadLocalSecurityContextHoldingStrategy(ThreadLocal
contextHolder) {
this(contextHolder);
}
public void setContext(SecurityContext context)
{this.contextHolder.set(context);}
public SecurityContext getContext() {return (SecurityContext
this.contextHolder.get();}
}
public class InheritableThreadLocalSecurityContextHoldingStrategy
extends ThreadLocalSecurityContextHoldingStrategy {
public InheritableThreadLocalSecurityContextHoldingStrategy() {
super(new InheritableThreadLocal());
}
}
public class GlobalSecurityContextHoldingStrategy implements
SecurityContextHoldingStrategy {
private SecurityContext globalContext;
public void setContext(SecurityContext context)
{this.globalContext = context;}
public SecurityContext getContext() {return globalContext;}
}
class SecurityContextHolder {
private static SecurityContextHoldingStrategy contextHolder = new
InheritableThreadLocalSecurityContextHoldingStrategy();
public static void
setSecurityContextHoldingStrategy(SecurityContextHoldingStrategy
contextHolder) {
Assert.notNull(contextHolder,
"Only a non-null SecurityContextHoldingStrategy is
permitted");
this.contextHolder = contextHolder;
}
public static void setContext(SecurityContext context) {
Assert.notNull(context,
"Only non-null SecurityContext instances are permitted");
contextHolder.setContext(context);
}
public static SecurityContext getContext() {
if (contextHolder.getContext() == null) {
contextHolder.setContext(new SecurityContextImpl());
}
return (SecurityContext) contextHolder.getContext();
}
}
Fairly simple - would you'd want to provide an nice way to configure
this in an app context or leave it fairly "hard"
(MethodInvokingFactoryBean?) so it's not abused. Also would the
GlobalSecurityContextHoldingStrategy cause the app to misbehave if
Run-as replacement was used?
Ollie
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
