Author: chris.laprun(a)jboss.com Date: 2007-10-13 23:23:50 -0400 (Sat, 13 Oct 2007) New Revision: 8640 Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml docs/trunk/referenceGuide/en/modules/clustering.xml Log: - Minor content improvements. 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 22:06:52 UTC (rev 8639) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml 2007-10-14 03:23:50 UTC (rev 8640) @@ -163,8 +163,7 @@ </depends> </mbean> ]]></programlisting> - More information can be found <ulink - url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate&qu...;. + More information can be found <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate&qu...;. </para> </sect2> @@ -192,7 +191,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 service on one node of the cluster using the + So the portal run the Jackrabbit servicey 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 @@ -209,12 +208,11 @@ <title>Setup</title> <para>We are going to outline how to setup a two node cluster on the same machine in order to test JBoss Portal HA. The only missing part from the full fledged setup is the addition of a load balancer in front of Tomcat. However a lot of documentation - exist on the subject. A detailed step by step setup of Apache and mod_jk is available from the <ulink - url="http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jk1.2WithJBos... Wiki</ulink>.</para> + exist on the subject. A detailed step by step setup of Apache and mod_jk is available from the + <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jk1.2WithJBos... Wiki</ulink>.</para> <para>As we need two application servers running at the same time, we must avoid any conflict. For instance we will need Tomcat to bind its socket on two different ports otherwise a network conflict will occur. We will leverage - the service binding manager <ulink - url="http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch10.html&quo... chapter</ulink> of + the service binding manager <ulink url="http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch10.html&quo... chapter</ulink> of the JBoss AS documentation.</para> <para>The first step is to copy the <emphasis>all</emphasis> configuration of JBoss into two separate configurations that we name <emphasis>ports-01</emphasis> and <emphasis>ports-02</emphasis> : @@ -255,21 +253,30 @@ <para>Copy JBoss Portal HA to the deploy directory of the two configurations.</para> <!-- adding instruction about jboss cache versioning --> - <para> - <emphasis>JBoss Cache Configuration Note :</emphasis> To improve CMS performance JBoss Cache is leveraged to cache the content cluster wide. - 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> - When building from source the following command: {core}/build.xml deploy-ha automatically upgrades your JBoss - Cache version. - </para> - <para> - <emphasis>Alternative: </emphasis> If upgrading your JBoss Cache version is not an option, the following configuration - change is needed in the jboss-portal-ha.sar/portal-cms.sar/META-INF/jboss-service.xml. - Replace the following configuration in the <emphasis>cms.pm.cache:service=TreeCache</emphasis> Mbean: - <programlisting><![CDATA[ + <note> + <para> + To improve CMS performance JBoss Cache is leveraged to cache the content cluster wide. + 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> + When building from source the following command: + <literal>{core}/build.xml deploy-ha</literal> automatically upgrades your JBoss Cache version. + </para> + <para> + <emphasis>Alternative:</emphasis> + If upgrading your JBoss Cache version is not an option, the following configuration + change is needed in the + <literal>jboss-portal-ha.sar/portal-cms.sar/META-INF/jboss-service.xml</literal>. + Replace the following configuration in the + <emphasis>cms.pm.cache:service=TreeCache</emphasis> + Mbean: + <programlisting><![CDATA[ <!-- Configuring the PortalCMSCacheLoader CacheLoader configuration for 1.4.0 @@ -288,7 +295,7 @@ </cacheloader> </config> </attribute>]]> - </programlisting> + </programlisting> with the following configuration: <programlisting><![CDATA[ <!-- @@ -305,10 +312,11 @@ <attribute name="CacheLoaderFetchPersistentState">false</attribute> <attribute name="CacheLoaderAsynchronous">false</attribute> ]]></programlisting> - </para> + </para> + </note> - <para>Finally we can start both servers, open two shells and execute : + <para>Finally we can start both servers, open two shells and execute : <programlisting><![CDATA[ @@ -320,8 +328,6 @@ </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 @@ -341,19 +347,20 @@ <listitem>Replicate only the portlet that requires it.</listitem> <listitem>Portal session replication is just web application replication and is very standard.</listitem> </itemizedlist> - <para>There are also some limitation such has you can only replicate portlet scoped attributes of a portlet - session. It means that any attribute scoped using application scope are not replicated.</para> + <para>There are, however, some limitations. For example, you can only replicate portlet-scoped attributes of a portlet + session. This means that any application-scoped attribute are not replicated.</para> <sect2> <title>JBoss Portal configuration</title> <para>The mandatory step to make JBoss Portal able to replicate portlet sessions is to configure - the portal web application to be distributed which is explained in <xref linkend="PortalSessionReplication"/></para> + the portal web application to be distributed as explained in <xref linkend="PortalSessionReplication"/></para> </sect2> <sect2> <title>Portlet configuration</title> - <para>In order to activate portlet session replication you need to</para> + <para>In order to activate portlet session replication you need to:</para> <itemizedlist> - <listitem>Add a specific listener class to the <emphasis>/WEB-INF/web.xml</emphasis> file of your web application</listitem> - <listitem>Configure your portlet to be distributed in the <emphasis>/WEB-INF/jboss-portlet.xml</emphasis> file.</listitem> + <listitem>Add a Portal-specific listener class to the <literal>/WEB-INF/web.xml</literal> file of your + portlet web application</listitem> + <listitem>Configure your portlet to be distributed in the <literal>/WEB-INF/jboss-portlet.xml</literal> file</listitem> </itemizedlist> <para> <programlisting><![CDATA[ @@ -397,7 +404,7 @@ is to keep consistency with the session state. If accessing a portlet would trigger replication of application scoped attribute during the rendering of a page then another portlet on the same page could use this attribute for generating its markup. Then the state seen by this second portlet - would not be the same according to the order in which the portlets of this page are rendered.</listitem> + would not necessarily be the same depending on the order in which the portlets on this page are rendered.</listitem> <listitem>Mutable objects need an explicit call to <emphasis>setAttribute(String name, Object value)</emphasis> on the portlet session object in order to trigger replication by the container.</listitem> </itemizedlist> Modified: docs/trunk/referenceGuide/en/modules/clustering.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/clustering.xml 2007-10-13 22:06:52 UTC (rev 8639) +++ docs/trunk/referenceGuide/en/modules/clustering.xml 2007-10-14 03:23:50 UTC (rev 8640) @@ -163,8 +163,7 @@ </depends> </mbean> ]]></programlisting> - More information can be found <ulink - url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate&qu...;. + More information can be found <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate&qu...;. </para> </sect2> @@ -192,7 +191,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 service on one node of the cluster using the + So the portal run the Jackrabbit servicey 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 @@ -209,12 +208,11 @@ <title>Setup</title> <para>We are going to outline how to setup a two node cluster on the same machine in order to test JBoss Portal HA. The only missing part from the full fledged setup is the addition of a load balancer in front of Tomcat. However a lot of documentation - exist on the subject. A detailed step by step setup of Apache and mod_jk is available from the <ulink - url="http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jk1.2WithJBos... Wiki</ulink>.</para> + exist on the subject. A detailed step by step setup of Apache and mod_jk is available from the + <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jk1.2WithJBos... Wiki</ulink>.</para> <para>As we need two application servers running at the same time, we must avoid any conflict. For instance we will need Tomcat to bind its socket on two different ports otherwise a network conflict will occur. We will leverage - the service binding manager <ulink - url="http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch10.html&quo... chapter</ulink> of + the service binding manager <ulink url="http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch10.html&quo... chapter</ulink> of the JBoss AS documentation.</para> <para>The first step is to copy the <emphasis>all</emphasis> configuration of JBoss into two separate configurations that we name <emphasis>ports-01</emphasis> and <emphasis>ports-02</emphasis> : @@ -255,21 +253,30 @@ <para>Copy JBoss Portal HA to the deploy directory of the two configurations.</para> <!-- adding instruction about jboss cache versioning --> - <para> - <emphasis>JBoss Cache Configuration Note :</emphasis> To improve CMS performance JBoss Cache is leveraged to cache the content cluster wide. - 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> - When building from source the following command: {core}/build.xml deploy-ha automatically upgrades your JBoss - Cache version. - </para> - <para> - <emphasis>Alternative: </emphasis> If upgrading your JBoss Cache version is not an option, the following configuration - change is needed in the jboss-portal-ha.sar/portal-cms.sar/META-INF/jboss-service.xml. - Replace the following configuration in the <emphasis>cms.pm.cache:service=TreeCache</emphasis> Mbean: - <programlisting><![CDATA[ + <note> + <para> + To improve CMS performance JBoss Cache is leveraged to cache the content cluster wide. + 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> + When building from source the following command: + <literal>{core}/build.xml deploy-ha</literal> automatically upgrades your JBoss Cache version. + </para> + <para> + <emphasis>Alternative:</emphasis> + If upgrading your JBoss Cache version is not an option, the following configuration + change is needed in the + <literal>jboss-portal-ha.sar/portal-cms.sar/META-INF/jboss-service.xml</literal>. + Replace the following configuration in the + <emphasis>cms.pm.cache:service=TreeCache</emphasis> + Mbean: + <programlisting><![CDATA[ <!-- Configuring the PortalCMSCacheLoader CacheLoader configuration for 1.4.0 @@ -288,7 +295,7 @@ </cacheloader> </config> </attribute>]]> - </programlisting> + </programlisting> with the following configuration: <programlisting><![CDATA[ <!-- @@ -305,10 +312,11 @@ <attribute name="CacheLoaderFetchPersistentState">false</attribute> <attribute name="CacheLoaderAsynchronous">false</attribute> ]]></programlisting> - </para> + </para> + </note> - <para>Finally we can start both servers, open two shells and execute : + <para>Finally we can start both servers, open two shells and execute : <programlisting><![CDATA[ @@ -320,8 +328,6 @@ </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 @@ -341,19 +347,20 @@ <listitem>Replicate only the portlet that requires it.</listitem> <listitem>Portal session replication is just web application replication and is very standard.</listitem> </itemizedlist> - <para>There are also some limitation such has you can only replicate portlet scoped attributes of a portlet - session. It means that any attribute scoped using application scope are not replicated.</para> + <para>There are, however, some limitations. For example, you can only replicate portlet-scoped attributes of a portlet + session. This means that any application-scoped attribute are not replicated.</para> <sect2> <title>JBoss Portal configuration</title> <para>The mandatory step to make JBoss Portal able to replicate portlet sessions is to configure - the portal web application to be distributed which is explained in <xref linkend="PortalSessionReplication"/></para> + the portal web application to be distributed as explained in <xref linkend="PortalSessionReplication"/></para> </sect2> <sect2> <title>Portlet configuration</title> - <para>In order to activate portlet session replication you need to</para> + <para>In order to activate portlet session replication you need to:</para> <itemizedlist> - <listitem>Add a specific listener class to the <emphasis>/WEB-INF/web.xml</emphasis> file of your web application</listitem> - <listitem>Configure your portlet to be distributed in the <emphasis>/WEB-INF/jboss-portlet.xml</emphasis> file.</listitem> + <listitem>Add a Portal-specific listener class to the <literal>/WEB-INF/web.xml</literal> file of your + portlet web application</listitem> + <listitem>Configure your portlet to be distributed in the <literal>/WEB-INF/jboss-portlet.xml</literal> file</listitem> </itemizedlist> <para> <programlisting><![CDATA[ @@ -397,7 +404,7 @@ is to keep consistency with the session state. If accessing a portlet would trigger replication of application scoped attribute during the rendering of a page then another portlet on the same page could use this attribute for generating its markup. Then the state seen by this second portlet - would not be the same according to the order in which the portlets of this page are rendered.</listitem> + would not necessarily be the same depending on the order in which the portlets on this page are rendered.</listitem> <listitem>Mutable objects need an explicit call to <emphasis>setAttribute(String name, Object value)</emphasis> on the portlet session object in order to trigger replication by the container.</listitem> </itemizedlist>