github
/
spring-security
镜像自地址 https://github.com/spring-projects/spring-security


			
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
							<?xml version="1.0" encoding="ISO-8859-1"?>
<document><properties><title>Acegi Security - Upgrading from version 0.8.0 to 0.9.0</title></properties><body><section name="Upgrading from 0.8.0 to 0.9.0"><p>
The following should help most casual users of the project update their
applications:

    <ul>

    <li>The most significant change in 0.9.0 is that <code>ContextHolder</code> 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 <code>ThreadLocal</code> per use case, 
    instead of a shared <code>ThreadLocal</code> for multiple use cases as the previous 
    <code>ContextHolder</code> allowed. <b>This is an important change in 0.9.0.</b> Many applications
    will need to modify their code (and possibly web views) if they directly interact with the old 
    <code>ContextHolder</code>. The replacement security <code>ThreadLocal</code> is called
    <a href="../multiproject/acegi-security/xref/net/sf/acegisecurity/context/SecurityContextHolder.html">
    SecurityContextHolder</a> and provides a single getter/setter for a
    <a href="../multiproject/acegi-security/xref/net/sf/acegisecurity/context/SecurityContextHolder.html">SecurityContext</a>.
    <code>SecurityContextHolder</code> guarantees to never return a <code>null</code> <code>SecurityContext</code>.
    <code>SecurityContext</code> provides single getter/setter for <code>Authentication</code>.<br></br><br></br>
    
    To migrate, simply modify all your code that previously worked with <code>ContextHolder</code>,
    <code>SecureContext</code> and <code>Context</code> to directly call <code>SecurityContextHolder</code>
    and work with the <code>SecurityContext</code> (instead of the now removed <code>Context</code>
    and <code>SecureContext</code> interfaces).<br></br><br></br>
    
    For example, change:<br></br>
    <code>
	SecureContext ctx = SecureContextUtils.getSecureContext();<br></br> 
	</code>
	to:<br></br>
    <code>
	SecurityContext ctx = SecurityContextHolder.getContext();<br></br> 
	</code>
	<br></br>
    and change:<br></br>
    <code>
	&lt;bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"&gt;<br></br> 
        &lt;property name="context"&gt;&lt;value&gt;net.sf.acegisecurity.context.security.SecureContextImpl&lt;/value&gt;&lt;/property&gt;<br></br> 
	&lt;/bean&gt;<br></br>
	</code>
	to:<br></br>
    <code>
	&lt;bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"&gt;<br></br>
        &lt;property name="context"&gt;&lt;value&gt;net.sf.acegisecurity.context.SecurityContextImpl&lt;/value&gt;&lt;/property&gt;<br></br>
	&lt;/bean&gt;<br></br>
	</code>
	<br></br>
    
    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 <code>Context</code>
    implementations, your applications no longer need to perform checking of <code>null</code> and
    unexpected <code>Context</code> implementation types.<br></br><br></br></li>

    <li><code>AbstractProcessingFilter</code> has changed its getter/setter approach used for customised
    authentication exception directions. See the <a href="../multiproject/acegi-security/xref/net/sf/acegisecurity/ui/AbstractProcessingFilter.html">
    <code>AbstractProcessingFilter</code> JavaDocs</a> to learn more.<br></br><br></br></li>
    
    <li><code>AnonymousProcessingFilter</code> now has a <code>removeAfterRequest</code> property, which defaults to <code>true</code>. 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 <code>HttpSession</code> in <code>HttpSessionContextIntegrationFilter</code>. You may
    set this property to false if you would like the anoymous authentication token to be preserved,
    which would be an unusual requirement.<br></br><br></br></li>
    
	<li>Event publishing has been refactored. New event classes have been added, and the location of
	<code>LoggerListener</code> has changed. See the <code>net.sf.acegisecurity.event package</code>.<br></br>
	<br></br>
    For example, change:<br></br>
    <code>
	&lt;bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/&gt;<br></br>
	</code>
	to:<br></br>
    <code>
	&lt;bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/&gt; 
	</code><br></br><br></br>	
	</li>
		
	<li>Users of the <code>&lt;authz:authentication&gt;</code> JSP tag will generally need to set the <code>operation</code>
	property equal to "username", as reflection is now used to retrieve the property displayed.<br></br><br></br></li>
		
	<li>
	Users of <code>net.sf.acegisecurity.wrapper.ContextHolderAwareRequestFilter</code> should note that it has been
	renamed to <code>net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter</code>.<br></br><br></br>
	</li>
		
	<li>
	The concurrent session support handling has changed. Please refer to the Reference Guide to
	review the new configuration requirements.<br></br><br></br>
	</li>
				
		
    </ul>


</p></section></body></document>