[portal-commits] JBoss Portal SVN: r8633 - in docs: trunk/referenceGuide/en/modules and 1 other directory.

Author: chris.laprun(a)jboss.com Date: 2007-10-13 14:07:51 -0400 (Sat, 13 Oct 2007) New Revision: 8633 Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml docs/trunk/referenceGuide/en/modules/clustering.xml Log: - Fixed typo. Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml =================================================================== --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml 2007-10-13 17:31:51 UTC (rev 8632) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml 2007-10-13 18:07:51 UTC (rev 8633) @@ -192,7 +192,7 @@ <sect2> <title>CMS clustering</title> <para>The CMS backend storage relies on the Apache Jackrabbit project. Jackrabbit does not support clustering out of the box. - So the portal run the Jackrabbit servicey on one node of the cluster using the + So the portal run the Jackrabbit service on one node of the cluster using the <ulink url="http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.... technology. The file <emphasis>jboss-portal.sar/portal-cms.sar/META-INF/jboss-service.xml</emphasis> contains the configuration. We will not reproduce it in this documentation as the changes are quite complex and numerous. Access from all nodes of the cluster @@ -260,10 +260,10 @@ We recommend that you use the following version of JBoss Cache for best performance: <itemizedlist> <listitem><emphasis>JBoss Cache 1.4.0.SP1 and above</emphasis></listitem> - <listitem><emphasis>JGroups 2.2.7 or 2.2.8</emphasis></listitem> - </itemizedlist> + <listitem><emphasis>JGroups 2.2.7 or 2.2.8</emphasis></listitem> + </itemizedlist> When building from source the following command: {core}/build.xml deploy-ha automatically upgrades your JBoss - Cache version. + Cache version. </para> <para> <emphasis>Alternative: </emphasis> If upgrading your JBoss Cache version is not an option, the following configuration @@ -304,10 +304,10 @@ <attribute name="CacheLoaderFetchTransientState">false</attribute> <attribute name="CacheLoaderFetchPersistentState">false</attribute> <attribute name="CacheLoaderAsynchronous">false</attribute> ]]></programlisting> - + </para> - - + + <para>Finally we can start both servers, open two shells and execute : <programlisting><![CDATA[ @@ -319,9 +319,9 @@ ]]></programlisting> </para> </sect1> - - + + <sect1 id="portlet_session_replication"> <title>Portlet Session Replication</title> <para>Web containers offer the capability to replicate sessions of web applications. In the context of a portal using portlets the use case is different. The portal itself is a web application Modified: docs/trunk/referenceGuide/en/modules/clustering.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/clustering.xml 2007-10-13 17:31:51 UTC (rev 8632) +++ docs/trunk/referenceGuide/en/modules/clustering.xml 2007-10-13 18:07:51 UTC (rev 8633) @@ -192,7 +192,7 @@ <sect2> <title>CMS clustering</title> <para>The CMS backend storage relies on the Apache Jackrabbit project. Jackrabbit does not support clustering out of the box. - So the portal run the Jackrabbit servicey on one node of the cluster using the + So the portal run the Jackrabbit service on one node of the cluster using the <ulink url="http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.... technology. The file <emphasis>jboss-portal.sar/portal-cms.sar/META-INF/jboss-service.xml</emphasis> contains the configuration. We will not reproduce it in this documentation as the changes are quite complex and numerous. Access from all nodes of the cluster