##### Overview

- Home
- Building with Maven
- Downloads

##### Documentation

- Suggested Steps
- Reference Guide
- Sample SQL Schema
- FAQ
- External Web Articles
- Products using Acegi
- Use without Spring
- Upgrading to 1.0.0
- Upgrading to 0.9.0
- Upgrading to 0.8.0
- Upgrading to 0.7.0
- Upgrading to 0.6
- Upgrading to 0.5
- Upgrading to 0.4
- Core JavaDocs
- Contacts HTTPS
- Project Policies

##### Projects

- Core Framework
- CAS Adapter
- Catalina Adapter
- JBoss Adapter
- Jetty Adapter
- Resin Adapter

##### Samples

- Contacts
- Attributes

##### Search Acegi Security System for Spring

##### Project Documentation

- About Acegi Security System for Spring
- Downloads
- Project Info
- Project Reports
- Development Process

## Upgrading from 0.6 to 0.7.0

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

- UserDetails now has two extra methods. Most people who have extended Acegi Security's default User implementation of UserDetails will be fine, as the constructor sets sensible defaults for the extra methods. People who have written their own UserDetails implementation from scratch will need to add the additional two methods. Returning true to both methods will normally be correct.
- AutoIntegrationFilter has been removed. User should instead use HttpSessionIntegrationFilter (in most cases), or HttpRequestIntegrationFilter (if using most container adapters) or JbossIntegrationFilter (if using the JBoss container adapter).
- MethodDefinitionMap, which is usually used by MethodSecurityInterceptor for its objectDefinitionSource property, has been changed. From 0.7.0, when MethodDefinitionMap is queried for configuration attributes associated with secure MethodInvocations, it will use any method matching in the method invocation class (as it always has) plus any method matching any interface the MethodInvocation class directly implements. So consider a PersonManager interface, a PersonManagerImpl class that implements it, and a definition of PersonManager.findAll=ROLE_FOO. In this example, any query for either PersonManager.findAll OR PersonManagerImpl.findAll will return ROLE_FOO. As we have always encouraged definition against the interface names (as per this example), this change should not adversely impact users. This change was necessary because of the new MethodDefinitionSourceAdvisor (see below). Refer to the MethodDefinitionMap JavaDocs for further clarification.
- MethodDefinitionSourceAdvisor can now be used instead of defining proxies for secure business objects. The advisor is fully compatible with both MethodDefinitionMap and MethodDefinitionAttributes. Using an advisor allows caching of which methods the MethodSecurityInterceptor should handle, thus providing a performance benefit as MethodSecurityInterceptor is not called for public (non-secure) objects. It also simplifies configuration.
- MethodSecurityInterceptor has moved from net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor to net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor. A simple find and replace will suffice to update your application contexts.
- All of the EH-CACHE cache implementations provided with Acegi Security have now been refactored to use a net.sf.ehcache.Cache obtained from EhCacheManagerFactoryBean, which is included with Spring 1.1.1 and above. See http://opensource.atlassian.com/confluence/spring/display/DISC/Caching+the+result+of+methods+using+Spring+and+EHCache for more about this bean, or the Contacts sample application for how to configure the EH-CACHE implementations provided with Acegi Security. Note the "cache" property is now required, and the old internally-managed cache properties have been removed.