Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Ben A. <ben...@ac...>]

Juergen Hoeller wrote:

>I've also taken the two convenience methods in Acegi's StringSplitUtils
>class and moved them over to Spring's StringUtils. In the course of this,
>I've transformed the "splitEachArrayElementAndCreateMap" method into
>"splitArrayElementsIntoProperties", essentially returning a Properties
>instance instead of a Map (since all we ever get back is String-String
>pairs).
>
>My goal for Spring 1.2 final is that the Acegi util package should only
>contain Acegi-specific utilities, no general utility stuff anymore. With the
>addition of DelegatingFilterProxy and the String split methods to core
>Spring, we should be pretty there... An Acegi release 0.9 alongside Spring
>1.2 final would be appropriate, I guess. Opinions welcome, of course :-)
>
>Ben, when do you plan to go to 1.0 RC with Acegi? Maybe alongside Spring 1.3
>RC, which is currently scheduled for right before JavaOne? I think that
>would be a great message, to show that Acegi is fully active and supported.
>
>(BTW, FilterChainProxy in net.sf.acegisecurity.util has dependencies on the
>net.sf.acegisecurity and net.sf.acegisecurity.intercept.web packages, so
>arguably doesn't belong in the low-level util package...)
>
Hi Juergen

All of this sounds great. Our general release plan at this stage is:

- Release 0.8.2. To release ASAP. It will require Spring 1.2-RC2, and 
fix the current 0.8.1 to 1.2-RC2 incompatibility.
- Release 0.9.0. Refactor to use a dedicated SecurityContext ThreadLocal 
and also Spring 1.2-Final util package migration.
- Release 1.0.0-RC1. A Spring 1.3 pre-JavaOne release sounds like a good 
target.

In terms of your other email's suggestion to use a SecurityContext 
ThreadLocal instead of ContextHolder, I've given this some more thought 
and we can do this and still offer a clean migration path for 99% of 
existing ContextHolder users. Whilst I know some people (myself 
included) have found ContextHolder's general-purpose approach useful, it 
seems more important overall to achieve standardization with Spring Core 
in the ThreadLocal approach, and as such it seems worthwhile refactoring 
to SecurityContext.

Any comments from the community are welcome.

Cheers
Ben