Upgrading from 0.8.0 to 0.9.0

The following should help most casual users of the project update their applications:

• The most significant change in 0.9.0 is that ContextHolder and all of its related classes have been removed. This significant change was made for the sake of consistency with the core Spring project's approach of a single ThreadLocal per use case, instead of a shared ThreadLocal for multiple use cases as the previous ContextHolder allowed. This is an important change in 0.9.0. Many applications will need to modify their code (and possibly web views) if they directly interact with the old ContextHolder. The replacement security ThreadLocal is called SecurityContextHolder and provides a single getter/setter for a SecurityContext. SecurityContextHolder guarantees to never return a null SecurityContext. SecurityContext provides single getter/setter for Authentication.
  
  To migrate, simply modify all your code that previously worked with ContextHolder, SecureContext and Context to directly call SecurityContextHolder and work with the SecurityContext (instead of the now removed Context and SecureContext interfaces).
  
  For example, change:
  SecureContext ctx = SecureContextUtils.getSecureContext();
to:
  SecurityContext ctx = SecurityContextHolder.getContext();

  and change:
  <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
<property name="context"><value>net.sf.acegisecurity.context.security.SecureContextImpl</value></property>
</bean>
to:
  <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
<property name="context"><value>net.sf.acegisecurity.context.SecurityContextImpl</value></property>
</bean>

  We apologise for the inconvenience, but on a more positive note this means you receive strict type checking, you no longer need to mess around with casting to and from Context implementations, your applications no longer need to perform checking of null and unexpected Context implementation types.
  
  
• AbstractProcessingFilter has changed its getter/setter approach used for customised authentication exception directions. See the AbstractProcessingFilter JavaDocs to learn more.
  
  
• AnonymousProcessingFilter now has a removeAfterRequest property, which defaults to true. This will cause the anonymous authentication token to be set to null at the end of each request, thus avoiding the expense of creating a HttpSession in HttpSessionContextIntegrationFilter. You may set this property to false if you would like the anoymous authentication token to be preserved, which would be an unusual requirement.
  
  
• Event publishing has been refactored. New event classes have been added, and the location of LoggerListener has changed. See the net.sf.acegisecurity.event package.
  
  For example, change:
  <bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/>
to:
  <bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/>
  
  
• Users of the <authz:authentication> JSP tag will generally need to set the operation property equal to "username", as reflection is now used to retrieve the property displayed.
  
  
• Users of net.sf.acegisecurity.wrapper.ContextHolderAwareRequestFilter should note that it has been renamed to net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.
  
  
• The concurrent session support handling has changed. Please refer to the Reference Guide to review the new configuration requirements.