[Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext

[Colin S. <col...@ex...>]

Ben Alex wrote:

> Pursuant to Juergen's recommendation 
> (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), 
> Acegi Security CVS has now had its ContextHolder and related classes 
> removed. This functionality has been replaced by SecurityContext, 
> which is an InheritableThreadLocal that provides a single 
> getter/setter pair for Authentication.
>
> This is a significant change for end users, but offers a number of 
> benefits:
>
> - Consistency with Spring core's use of a concrete ThreadLocal per 
> functional area
> - SecurityContext is strictly typed (which eliminates the need for 
> casting)
> - Simplified configuration as no need to specify a Context 
> implementation for HttpSessionContextIntegrationFilter
> - InheritableThreadLocal used instead of ThreadLocal to simplify rich 
> client usage (see http://forum.springframework.org/viewtopic.php?t=5004)
> - Elimination of handling the extra Context layer means less end user 
> code is required
>
> Unit tests pass and I've updated the upgrade-080-090.txt in some 
> detail. The reference guide has also been updated.
>
> It would be appreciated if developers could try the latest CVS with 
> their applications and report any difficulties. General feedback on 
> this change is also welcome.

As I read Juergen's suggestion, I thought he was just suggesting to go 
away from the ContextHolder with abitlity to hold a generic Context, as 
it is potentially confusing as to what is going to go in there. So he 
suggested a SecurityContextHolder which needs to hold a SecurityContext.

However, it seems to me that this simplification is much more than that, 
and may have gone too far, as it's all been collapsed into the one 
SecurityContext which is the threadlocal (effectively) and holds the 
Authentication. Unless I'm missing something it would still be of real 
use to have a real SecurityContextHolder which holds a pluggable 
SecurityContext. Then people can subclass that if needed to add extra 
data. The difference from before however is that now it is clearly 
security focused, and the lifecycle of the object is managed clearly by 
Acegi.

What does everybody think?

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com