[jboss-cvs] JBossAS SVN: r94396 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US.

[jboss-cvs-commits at lists.jboss.org]

Author: laubai
Date: 2009-10-06 00:11:25 -0400 (Tue, 06 Oct 2009)
New Revision: 94396

Modified:
   projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
   projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
Log:
Removing invalid tags.

Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml	2009-10-06 04:07:28 UTC (rev 94395)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml	2009-10-06 04:11:25 UTC (rev 94396)
@@ -283,7 +283,7 @@
         Whenever there is a change in the cluster topology of the Foo service, the <literal>HAPartition</literal> service invokes a callback on Foo notifying it of the new topology.
         So, for example, when Foo started on D, the Foo service running on A, C and D all got callbacks telling them the new view for Foo was {A, C, D}.
         That callback gives each node enough information to independently decide if it is now the master.
-        The Foo service on each node uses the <literal>HAPartition</literal>'s <literal>HASingletonElectionPolicy</literal> to determine if they are the master, as explained in the <link linkend="ha-singleton-election-policy">next section</link>.
+        The Foo service on each node uses the <literal>HAPartition</literal>'s <literal>HASingletonElectionPolicy</literal> to determine if they are the master, as explained in the <xref linkend="ha-singleton-election-policy"/>.
       </para>
       <para>
         If A were to fail or shutdown, Foo on C and D would get a callback with a new view for Foo of {C, D}.
@@ -477,4 +477,4 @@
 
       </section>
       -->
-</chapter>
\ No newline at end of file
+</chapter>

Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml	2009-10-06 04:07:28 UTC (rev 94395)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml	2009-10-06 04:11:25 UTC (rev 94396)
@@ -515,7 +515,7 @@
 
       <para>Event notifications that may make sense in a non-clustered environment 
       may or may not make sense in a clustered environment; see 
-      <link linkend="https://jira.jboss.org/jira/browse/JBAS-5778">https://jira.jboss.org/jira/browse/JBAS-5778</link> 
+      <ulink url="https://jira.jboss.org/jira/browse/JBAS-5778">https://jira.jboss.org/jira/browse/JBAS-5778</ulink> 
       for an example of why a notification may not be desired. Configuring an appropriate 
       <literal>ClusteredSessionNotificationPolicy</literal> gives the application 
       author fine-grained control over what notifications are issued.</para>