Corrected links in manual, comment in schema file.

config/src/main/resources/org/springframework/security/config/spring-security-3.0.rnc

@@ -228,7 +228,7 @@ expression-handler =
     element expression-handler {ref}
 
 custom-after-invocation-provider =
-    ## Used to decorate an AfterInvocationProvider to specify that it should be used with method security.
+    ## No longer supported. Use after-invocation-provider instead.
     element custom-after-invocation-provider {empty}
 
 protect-pointcut =

docs/manual/src/docbook/appendix-namespace.xml

@@ -161,9 +161,9 @@
           there is no preference. If this attribute is present on any
             <literal>&lt;intercept-url&gt;</literal> element, then a
             <classname>ChannelProcessingFilter</classname> will be added to the filter stack and its
-          additional dependencies added to the application context. See the chapter on <link
+          additional dependencies added to the application context. <!--See the chapter on <link
             xlink:href="#channel-security-config">channel security</link> for an example
-          configuration using traditional beans. </para>
+          configuration using traditional beans. --></para>
         <para> If a <literal>&lt;port-mappings&gt;</literal> configuration is added, this will be
           used to by the <classname>SecureChannelProcessor</classname> and
             <classname>InsecureChannelProcessor</classname> beans to determine the ports used for
@@ -423,7 +423,7 @@
       <section>
         <title>The &lt;authentication-provider&gt; Element</title>
         <para> This element is basically a shorthand syntax for configuring a <link
-            xlink:href="#dao-provider"><classname>DaoAuthenticationProvider</classname></link>.
+          xlink:href="#core-services-dao-provider"><classname>DaoAuthenticationProvider</classname></link>.
             <classname>DaoAuthenticationProvider</classname> loads user information from a
             <interfacename>UserDetailsService</interfacename> and compares the username/password
           combination with the values supplied at login. The

docs/manual/src/docbook/core-services.xml

@@ -8,7 +8,7 @@
             <interfacename>AccessDecisionManager</interfacename>. These crop up regularly throughout
         the remainder of this document so it's important you know how they are configured and how
         they operate. </para>
-    <section xml:id="authentication-manager">
+    <section xml:id="core-services-authentication-manager">
         <title>The <interfacename>AuthenticationManager</interfacename>,
                 <classname>ProviderManager</classname> and
                 <classname>AuthenticationProvider</classname>s</title>
@@ -74,7 +74,7 @@
             concerned about this, because if you forget to register a suitable provider, you'll
             simply receive a <literal>ProviderNotFoundException</literal> when an attempt to
             authenticate is made.</para>
-        <section>
+        <section xml:id="core-services-dao-provider">
             <title><literal>DaoAuthenticationProvider</literal></title>
             <para>The simplest <interfacename>AuthenticationProvider</interfacename> implemented by
                 Spring Security is <literal>DaoAuthenticationProvider</literal>, which is is also
@@ -128,7 +128,7 @@
             should be easy for users to retrieve authentication information using a persistence
             strategy of their choice. Having said that, Spring Security does include a couple of
             useful base implementations, which we'll look at below.</para>
-        <section xml:id="in-memory-service">
+        <section xml:id="core-services-in-memory-service">
             <title>In-Memory Authentication</title>
             <para>Is easy to use create a custom <interfacename>UserDetailsService</interfacename>
                 implementation that extracts information from a persistence engine of choice, but
@@ -137,7 +137,7 @@
                 Security, when you don't really want to spend time configuring databases or writing
                     <interfacename>UserDetailsService</interfacename> implementations. For this sort
                 of situation, a simple option is to use the <literal>user-service</literal> element
-                from the security <link xlink:href="#namespace-minimal">namespace</link>: <programlisting><![CDATA[
+                from the security <link xlink:href="#ns-minimal">namespace</link>: <programlisting><![CDATA[
   <user-service id="userDetailsService">
     <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
     <user name="bob" password="bobspassword" authorities="ROLE_USER" />
@@ -153,7 +153,7 @@
  jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled
  bob=bobspassword,ROLE_USER,enabled</programlisting></para>
         </section>
-        <section xml:id="jdbc-service">
+        <section xml:id="core-services-jdbc-user-service">
             <title><literal>JdbcDaoImpl</literal></title>
             <para>Spring Security also includes a <interfacename>UserDetailsService</interfacename>
                 that can obtain authentication information from a JDBC data source. Internally

docs/manual/src/docbook/namespace-config.xml

@@ -177,7 +177,7 @@
         application (which will be used for access control). It is also possible to load user
         information from a standard properties file using the <literal>properties</literal>
         attribute on <literal>user-service</literal>. See the section on <link
-          xlink:href="#in-memory-service">in-memory authentication</link> for more details. Using
+          xlink:href="#core-services-in-memory-service">in-memory authentication</link> for more details. Using
         the <literal>&lt;authentication-provider&gt;</literal> element means that the user
         information will be used by the authentication manager to process authentication requests. </para>
       <para> At this point you should be able to start up your application and you will be required
@@ -366,8 +366,8 @@
       <port-mapping http="9080" https="9443"/>
     </port-mappings>
   </http>]]>
-        </programlisting> You can find a more in-depth discussion of channel security
-        in <xref xlink:href="#channel-security"/>. </para>
+        </programlisting> <!--You can find a more in-depth discussion of channel security
+        in <xref xlink:href="#channel-security"/--> </para>
     </section>
     <section xml:id="ns-concurrent-session">
       <title>Concurrent Session Control</title>
@@ -569,7 +569,7 @@
           element. </para>
         <para> The CAS sample application is a good example of the use of custom beans with the
           namespace, including this syntax. If you aren't familiar with authentication entry points,
-          they are discussed in the <link xlink:href="#tech-auth-entry-point">technical
+          they are discussed in the <link xlink:href="#tech-intro-auth-entry-point">technical
             overview</link> chapter. </para>
       </section>
     </section>

docs/manual/src/docbook/preauth.xml

@@ -111,7 +111,7 @@
     <section>
       <title>Http403ForbiddenEntryPoint</title>
       <para>
-        The <interfacename>AuthenticationEntryPoint</interfacename> was discussed in the <link xlink:href="#tech-auth-entry-point">technical
+        The <interfacename>AuthenticationEntryPoint</interfacename> was discussed in the <link xlink:href="#tech-intro-auth-entry-point">technical
         overview</link> chapter. Normally it is responsible for kick-starting the authentication process for an unauthenticated user
         (when they try to access a protected resource), but in the pre-authenticated case this doesn't apply. You would only
         configure the <classname>ExceptionTranslationFilter</classname> with an instance of this class if you aren't 

docs/manual/src/docbook/samples.xml

@@ -19,7 +19,7 @@
             namespace configuration throughout. The compiled application is included in the
             distribution zip file, ready to be deployed into your web container
                 (<filename>spring-security-samples-tutorial-3.0.x.war</filename>). The <link
-                xlink:href="#form">form-based</link> authentication mechanism is used in combination
+                    xlink:href="#ns-form-and-basic">form-based</link> authentication mechanism is used in combination
             with the commonly-used <link xlink:href="#remember-me">remember-me</link> authentication
             provider to automatically remember the login using cookies.</para>
         <para>We recommend you start with the tutorial sample, as the XML is minimal and easy to
@@ -117,6 +117,6 @@ Success! Your web filters appear to be properly configured!
                 xlink:href="#preauth">pre-authentication</link> framework to make use of login
             information from a J2EE container. The user name and roles are those setup by the
             container. </para>
-        <para> The code is in <filename>samples/preauth</filename> . </para>
+        <para> The code is in <filename>samples/preauth</filename>. </para>
     </section>
 </chapter>

docs/manual/src/docbook/security-filter-chain.xml

@@ -110,7 +110,7 @@
         <literal>false</literal> and servlet container lifecycle invocations are not delegated
       through <literal>DelegatingFilterProxy</literal>.</para>
     <para> When we looked at how to set up web security using <link
-        xlink:href="#namespace-auto-config">namespace configuration</link>, we used a
+      xlink:href="#ns-web-xml">namespace configuration</link>, we used a
         <literal>DelegatingFilterProxy</literal> with the name
         <quote>springSecurityFilterChain</quote>. You should now be able to see that this is the
       name of the <classname>FilterChainProxy</classname> which is created by the namespace. </para>

docs/manual/src/docbook/springsecurity.xml

@@ -10,7 +10,7 @@
       </author>
     </authorgroup>
     <productname>Spring Security</productname>
-    <releaseinfo>3.0.0.M1</releaseinfo>
+    <releaseinfo>3.0.0.M2</releaseinfo>
   </info>
   <toc/>
   <preface xml:id="preface">

docs/manual/src/docbook/technical-overview.xml

@@ -111,7 +111,7 @@ if (principal instanceof UserDetails) {
       <para> On successful authentication, <interfacename>UserDetails</interfacename> is used to
         build the <interfacename>Authentication</interfacename> object that is stored in the
           <classname>SecurityContextHolder</classname> (more on this <link
-          xlink:href="#tech-intro-authentication-mgr">below</link>). The good news is that we
+          xlink:href="#tech-intro-authentication">below</link>). The good news is that we
         provide a number of <interfacename>UserDetailsService</interfacename> implementations,
         including one that uses an in-memory map (<classname>InMemoryDaoImpl</classname>) and
         another that uses JDBC (<classname>JdbcDaoImpl</classname>). Most users tend to
@@ -322,7 +322,7 @@ Successfully authenticated. Security context contains: \
           work, and still provide authorization capabilities. All you need to do is write a filter
           (or equivalent) that reads the third-party user information from a location, build a
           Spring Security-specific <interfacename>Authentication</interfacename> object, and put it
-          onto the <classname>SecurityContextHolder</classname>.</para>
+          into the <classname>SecurityContextHolder</classname>.</para>
         <para> If you're wondering how the <interfacename>AuthenticationManager</interfacename>
           manager is implemented in a real world example, we'll look at that in </para>
       </section>