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[
cd $JBOSS_HOME/bin
@@ -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