| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 |
- <html>
- <head>
- <title>Acegi Security - Upgrading from version 0.6 to 0.7</title>
- </head>
- <body>
- <h1>Upgrading from 0.6 to 0.7.0</h1>
- <p>
- The following should help most casual users of the project update their
- applications:
- <ul>
- <li>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.
- </li>
- <li>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.</li>
- <li>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.</li>
- <li>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.</li>
- <li>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.</li>
- </ul>
- </body>
- </html>
|
