Quellcode durchsuchen

Move upgrade help files to xdocs/upgrade.

Ben Alex vor 21 Jahren
Ursprung
Commit
3b7453d243

+ 28 - 22
upgrade-03-04.txt → doc/xdocs/upgrade/upgrade-03-04.html

@@ -1,47 +1,53 @@
-===============================================================================
-          ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.3 TO 0.4
-===============================================================================
-
-Several changes were made between version 0.3 and 0.4 of the project.
+<html>
+<head>
+<title>Acegi Security - Upgrading from version 0.3 to 0.4</title>
+</head>
+<body>
+<h1>Upgrading from 0.3 to 0.4</h1>
+
+<p>Several changes were made between version 0.3 and 0.4 of the project.
 These changes increased the modularity of the code, enhanced unit testing,
 made package roles clearer, and added compelling alternatives to container
 adapters and using web.xml security constraints to protect HTTP resources.
 
-Unfortunately, changes to the API and package locations were required. The
+<p>Unfortunately, changes to the API and package locations were required. The
 following should help most casual users of the project update their
 applications:
 
-- All references to net.sf.acegisecurity.SecurityInterceptor become
-  net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor.
+<ul>
+<li>All references to net.sf.acegisecurity.SecurityInterceptor become
+  net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor.</li>
 
-- All references to net.sf.acegisecurity.MethodDefinitionAttributes become
-  net.sf.acegisecurity.intercept.method.MethodDefinitionAttributes.
+<li>All references to net.sf.acegisecurity.MethodDefinitionAttributes become
+  net.sf.acegisecurity.intercept.method.MethodDefinitionAttributes.</li>
 
-- All references to net.sf.acegisecurity.adapters.AutoIntegrationFilter become
-  net.sf.acegisecurity.ui.AutoIntegrationFilter (see your web.xml).
+<li>All references to net.sf.acegisecurity.adapters.AutoIntegrationFilter become
+  net.sf.acegisecurity.ui.AutoIntegrationFilter (see your web.xml).</li>
 
-- If you're using container adapters (extremely likely), consider replacing
+<li>If you're using container adapters (extremely likely), consider replacing
   them with the net.sf.acegisecurity.ui.webapp package. This will avoid
   the need to have JARs in your container classloader, and is a lot cleaner.
-  Refer to the reference documentation or Contacts sample application.
+  Refer to the reference documentation or Contacts sample application.</li>
 
-- If you're using web.xml <security-constraint>s for securing HTTP URLs
+<li>If you're using web.xml <security-constraint>s for securing HTTP URLs
   (extremely likely), consider replacing it with the
   net.sf.acegisecurity.intercept.web package. This will give you considerably
   more flexibility, and reuse the same concepts as you'd be familiar with
   via the method security interception system. Refer to the reference
-  documentation or Contacts sample application.
+  documentation or Contacts sample application.</li>
 
-- The Contacts sample application now builds two distributions: contacts.war
+<li>The Contacts sample application now builds two distributions: contacts.war
   can be instantly deployed without configuring any container adapters,
   whilst contacts-container-adapter.war still uses container adapters. The
   contacts.war uses the net.sf.acegisecurity.intercept.web package to
-  protect HTTP URLs, rather than web.xml <security-constraint>s.
+  protect HTTP URLs, rather than web.xml <security-constraint>s.</li>
 
-- If you're using the Jetty container adapter, please check the jetty.xml
-  requirements in the reference documentation. There has been a minor change.
+<li>If you're using the Jetty container adapter, please check the jetty.xml
+  requirements in the reference documentation. There has been a minor change.</li>
+</ul>
 
+<p>
 We hope you find the new features useful in your projects.
 
-
-$Id$
+</body>
+</html>

+ 28 - 20
upgrade-04-05.txt → doc/xdocs/upgrade/upgrade-04-05.html

@@ -1,51 +1,59 @@
-===============================================================================
-          ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.4 TO 0.5
-===============================================================================
-
-The following should help most casual users of the project update their
+<html>
+<head>
+<title>Acegi Security - Upgrading from version 0.4 to 0.5</title>
+</head>
+<body>
+<h1>Upgrading from 0.4 to 0.5</h1>
+
+<p>The following should help most casual users of the project update their
 applications:
+<ul>
 
-- All filters are now loaded via FilterToBeanProxy. The FilterToBeanProxy
+<li>All filters are now loaded via FilterToBeanProxy. The FilterToBeanProxy
   obtains the filter from a Spring application context via the
   WebApplicationContextUtils.getApplicationContext() method. Refer to the
-  reference documentation to see the new configuration of filters.
+  reference documentation to see the new configuration of filters.</li>
 
-- SecurityEnforcementFilter now requires an AuthenticationEntryPoint
+<li>SecurityEnforcementFilter now requires an AuthenticationEntryPoint
   and PortResolver. Refer to the reference documentation to see the
   alternatives AuthenticationEntryPoint implementations available. Simply
-  use the PortResolverImpl for the PortResolver requirement.
+  use the PortResolverImpl for the PortResolver requirement.</li>
 
-- Any of your login or login failure pages that previously referred to
+<li>Any of your login or login failure pages that previously referred to
   AuthenticationProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY
   should now use
-  net.sf.acegisecurity.ui.AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY
+  net.sf.acegisecurity.ui.AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY.</li>
 
-- DaoAuthenticationProvider no longer provides setters for case sensitivity
+<li>DaoAuthenticationProvider no longer provides setters for case sensitivity
   handling. The respective AuthenticationDao implementations should decide
   whether or not to return User instances reflecting the exact case of the
   requested username. The new PlaintextPasswordEncoder offers a setter for
-  ignoring the password case (defaults to require exact case matches).
+  ignoring the password case (defaults to require exact case matches).</li>
 
-- DaoAuthenticationProvider now provides caching. Successful authentications
+<li>DaoAuthenticationProvider now provides caching. Successful authentications
   return DaoAuthenticationTokens. You must set the mandatory "key" property
   on DaoAuthenticationProvider so these tokens can be validated. You may
   also wish to change the "refreshTokenInterval" property from the default
-  of 60,000 milliseconds.
+  of 60,000 milliseconds.</li>
 
-- If you're using container adapters, please refer to the reference
+<li>If you're using container adapters, please refer to the reference
   documentation as additional JARs are now required in your container
-  classloader.
+  classloader.</li>
 
-- Whilst not really a change needed to your program, if you're using
+<li>Whilst not really a change needed to your program, if you're using
   Acegi Security please consider joining the acegisecurity-developer mailing
   list. This is currently the best way to keep informed about the project's
   status and provide feedback in design discussions. You can join at 
   https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer.
-  Please continue using the Spring Users mailing list for general support.
+  Please continue using the Spring Users mailing list for general support.</li>
+</ul>
 
+<p>
 There are also lots of new features you might wish to consider for your
 projects. These include CAS integration, pluggable password encoders
 (such as MD5 and SHA), along with pluggable salt sources. We hope you find
 the new features useful in your projects.
 
-$Id$
+
+</body>
+</html>

+ 81 - 0
doc/xdocs/upgrade/upgrade-05-06.html

@@ -0,0 +1,81 @@
+<html>
+<head>
+<title>Acegi Security - Upgrading from version 0.3 to 0.4</title>
+</head>
+<body>
+<h1>Upgrading from 0.5 to 0.6</h1>
+
+<p>
+The following should help most casual users of the project update their
+applications:
+<ul>
+<li>
+Locate and remove all property references to 
+  DaoAuthenticationProvider.key and 
+  DaoAuthenticationProvider.refreshTokenInterval.</li>
+
+<li>If you are using DaoAuthenticationProvider and either (i) you are using
+  container adapters or (ii) your code relies on the Authentication object
+  having its getPrincipal() return a String, you must set the new
+  DaoAuthenticationProvider property, forcePrincipalAsString, to true.
+  By default DaoAuthenticationProvider returns an Authentication object
+  containing the relevant User, which allows access to additional properties.
+  Where possible, we recommend you change your code to something like this,
+  so that you can leave forcePrincipalAsString to the false default:<br><br>
+    <code>
+    String username = authentication.getPrincipal();<br>
+    if (authentication.getPrincipal() instanceof User) {<br>
+      username = ((User) authentication.getPrincipal()).getUsername();<br>
+    }</br>
+	</code><br>
+</li>
+
+<li>The signature of AuthenticationDaos have changed. In concrete
+  implementations, modify the User to UserDetails, as shown below:<br><br>
+    <code>
+    public User loadUserByUsername(String username)<br>
+        throws UsernameNotFoundException, DataAccessException {<br><br>
+
+    to:<br><br>
+  
+    public UserDetails loadUserByUsername(String username)<br>
+        throws UsernameNotFoundException, DataAccessException {<br><br>
+	</code>
+
+  Existing concrete implementations would be returning User, which implements
+  UserDetails, so no further code changes should be required.
+</li>
+<li>Similar signature changes (User -> UserDetails) are also required to any
+  custom implementations of UserCache and SaltSource.</li>
+
+<li>Any custom event listeners relying on AuthenticationEvent should note a
+  UserDetails is now provided in the AuthenticationEvent (not a User).</li>
+
+<li>CAS users should note the CasAuthoritiesPopulator interface signature has
+  changed. Most CAS users will be using DaoCasAuthoritiesPopulator, so this
+  change is unlikely to require any action.</li>
+
+<li>Please check your web.xml for whether you are using AutoIntegrationFilter.
+  Previously this class was loaded directly by web.xml as a filter. It is
+  now recommended to load it via FilterToBeanProxy and define it as a
+  bean in your application context. This usually involves making the entry
+  in web.xml match the following:<br><br>
+  <code>
+    &lt;filter&gt;<br>
+        &lt;filter-name&gt;Acegi Security System for Spring Auto Integration Filter&lt;/filter-name&gt;<br>
+        &lt;filter-class&gt;net.sf.acegisecurity.util.FilterToBeanProxy&lt;/filter-class&gt;<br>
+        &lt;init-param&gt;<br>
+            &lt;param-name&gt;targetClass&lt;/param-name&gt;<br>
+            &lt;param-value&gt;net.sf.acegisecurity.ui.AutoIntegrationFilter&lt;/param-value&gt;<br>
+        &lt;/init-param&gt;<br>
+    &lt;/filter&gt;<br>
+  </code>
+  <br><br>
+  Then add the following to applicationContext.xml:  <br><br>
+  <code>
+  	&lt;bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/&gt;<br>
+  </code>
+</li>
+</ul>
+</body>
+</html>

+ 17 - 12
upgrade-06-07.txt → doc/xdocs/upgrade/upgrade-06-07.html

@@ -1,11 +1,15 @@
-===============================================================================
-          ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.6 TO 0.7
-===============================================================================
+<html>
+<head>
+<title>Acegi Security - Upgrading from version 0.6 to 0.7</title>
+</head>
+<body>
+<h1>Upgrading from 0.6 to 0.7</h1>
 
+<p>
 The following should help most casual users of the project update their
 applications:
-
-- MethodDefinitionMap, which is usually used by MethodSecurityInterceptor
+<ul>
+<li>MethodDefinitionMap, which is usually used by MethodSecurityInterceptor
   for its objectDefinitionSource property, has been changed. From 0.7, when
   MethodDefinitionMap is queried for configuration attributes associated with
   secure MethodInvocations, it will use any method matching in the method
@@ -17,18 +21,19 @@ applications:
   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.
+  Refer to the MethodDefinitionMap JavaDocs for further clarification.</li>
 
-- MethodDefinitionSourceAdvisor can now be used instead of defining proxies
+<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.
+  for public (non-secure) objects. It also simplifies configuration.</li>
 
-- MethodSecurityInterceptor has moved from
+<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.
-
-$Id$
+  A simple find and replace will suffice to update your application contexts.</li>
+</ul>
+</body>
+</html>

+ 0 - 70
upgrade-05-06.txt

@@ -1,70 +0,0 @@
-===============================================================================
-          ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.5 TO 0.6
-===============================================================================
-
-The following should help most casual users of the project update their
-applications:
-
-- Locate and remove all property references to 
-  DaoAuthenticationProvider.key and 
-  DaoAuthenticationProvider.refreshTokenInterval.
-
-- If you are using DaoAuthenticationProvider and either (i) you are using
-  container adapters or (ii) your code relies on the Authentication object
-  having its getPrincipal() return a String, you must set the new
-  DaoAuthenticationProvider property, forcePrincipalAsString, to true.
-  By default DaoAuthenticationProvider returns an Authentication object
-  containing the relevant User, which allows access to additional properties.
-  Where possible, we recommend you change your code to something like this,
-  so that you can leave forcePrincipalAsString to the false default:
-  
-    String username = authentication.getPrincipal();
-    if (authentication.getPrincipal() instanceof User) {
-      username = ((User) authentication.getPrincipal()).getUsername();
-    }
-
-- The signature of AuthenticationDaos have changed. In concrete
-  implementations, modify the User to UserDetails, as shown below:
-
-    public User loadUserByUsername(String username)
-        throws UsernameNotFoundException, DataAccessException {
-
-    to:
-  
-    public UserDetails loadUserByUsername(String username)
-        throws UsernameNotFoundException, DataAccessException {
-
-  Existing concrete implementations would be returning User, which implements
-  UserDetails, so no further code changes should be required.
-
-- Similar signature changes (User -> UserDetails) are also required to any
-  custom implementations of UserCache and SaltSource.
-
-- Any custom event listeners relying on AuthenticationEvent should note a
-  UserDetails is now provided in the AuthenticationEvent (not a User).
-
-- CAS users should note the CasAuthoritiesPopulator interface signature has
-  changed. Most CAS users will be using DaoCasAuthoritiesPopulator, so this
-  change is unlikely to require any action.
-
-- Please check your web.xml for whether you are using AutoIntegrationFilter.
-  Previously this class was loaded directly by web.xml as a filter. It is
-  now recommended to load it via FilterToBeanProxy and define it as a
-  bean in your application context. This usually involves making the entry
-  in web.xml match the following:
-  
-    <filter>
-        <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
-        <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
-        <init-param>
-            <param-name>targetClass</param-name>
-            <param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value>
-        </init-param>
-    </filter>
-
-  Then add the following to applicationContext.xml:
-  
-  	<bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter" />
-
-
-$Id$