# 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.