[jboss-cvs] JBossAS SVN: r99055 - projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Jan 5 23:34:03 EST 2010
Author: laubai
Date: 2010-01-05 23:34:03 -0500 (Tue, 05 Jan 2010)
New Revision: 99055
Modified:
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Security.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml
Log:
Corrected tags in Clustering Building Blocks and Concepts chapters.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -723,7 +723,6 @@
</section>
-<!--HAJIME-->
<section>
<title>Support Foreign Keys in CMP Services</title>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,16 +4,16 @@
<bookinfo id="Administration_And_Configuration_Guide">
<title>Administration And Configuration Guide</title>
- <subtitle>for JBoss Enterprise Application Platform 5.0</subtitle>
+ <subtitle>for JBoss Enterprise Web Platform 5.0</subtitle>
<edition>1</edition>
<issuenum>1</issuenum>
- <pubsnumber>4</pubsnumber>
- <productname>JBoss Enterprise Application Platform</productname>
+ <pubsnumber>0.1</pubsnumber>
+ <productname>JBoss Enterprise Web Platform</productname>
<productnumber>5.0</productnumber>
<!-- <pubdate>, 2009</pubdate> -->
<abstract>
<para>
- This book is a guide to the administration and configuration of JBoss Enterprise Application Platform 5.0.
+ This book is a guide to the administration and configuration of JBoss Enterprise Web Platform 5.0.
</para>
</abstract>
<corpauthor>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -60,7 +60,7 @@
<para>When a change is made to an object in the cache and that change is performed in the context of a transaction, the replication of changes is deferred until the transaction commits successfully. All modifications are kept in a list associated with the transaction for the caller. When the transaction commits, we replicate the changes. Otherwise, on a rollback, we simply undo the changes locally, resulting in zero network traffic and overhead. For example, if a caller makes 100 modifications and then rolls back the transaction, we will not replicate anything, resulting in no network traffic. </para>
<para>If a caller has no transaction associated with it (and its isolation level is not <literal>NONE</literal> — more about this later), we will replicate immediately after each modification. In the above case we would send 100 messages, plus an additional message for the rollback. In this sense, running without a transaction can be thought of as analogous to running with auto-commit switched on in JDBC terminology, where each operation is committed automatically. </para>
<para>JBoss Cache works out of the box with most popular transaction managers, and even provides an API where custom transaction manager lookups can be written. </para>
- <para>The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree of concurrency can be tuned using a number of isolation levels, corresponding to database-style transaction isolation levels, i.e., SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED and NONE. Concurrency, locking and isolation levels will be discussed later. </para>
+ <para>The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree of concurrency can be tuned using a number of isolation levels, corresponding to database-style transaction isolation levels: <literal>SERIALIZABLE</literal>, <literal>REPEATABLE_READ</literal>, <literal>READ_COMMITTED</literal>, <literal>READ_UNCOMMITTED</literal> and <literal>NONE</literal>. Concurrency, locking and isolation levels will be discussed later. </para>
</section>
@@ -68,7 +68,7 @@
<title>Running JBoss Cache in the JBoss Application server</title>
<para>
<indexterm><primary>JBoss Enterprise Web Platform</primary><secondary>running JBoss Cache with JBoss Enterprise Web Platform</secondary></indexterm>
- JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend="jgroups"/>
+ JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found in <xref linkend="jgroups"/>
</para>
<!--<para>The following is the JBoss Cache JGroups and JBoss Enterprise Web Platform compatibility matrix.</para>
@@ -204,7 +204,6 @@
<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss Enterprise Web Platform 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>-->
-<para>
<!--
<table frame="all"><title>JBoss Enterprise Web Platform + Jgroups compatibility matrix</title>
<tgroup cols="3"><tbody>
@@ -421,9 +420,8 @@
</entry>
</row></tbody></tgroup>
</table>-->
-</para>
-<para>
+
<!--<table frame="all"><title>JBoss Cache + Jgroups compatibility matrix</title>
<tgroup cols="3"><tbody>
<row>
@@ -582,55 +580,69 @@
</entry>
</row></tbody></tgroup>
</table>-->
+
+<para>
+ In the JBoss Enterprise Web Platform 5, JBoss Cache runs in the <literal>all</literal> configuration of the Enterprise Web Platform (for instance, <filename>$JBOSS_HOME/server/all</filename>). All you need to do is start the server with this configuration.
</para>
-
-<para>In the JBoss Enterprise Web Platform 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the Enterprise Web Platform (for instance, <JBOSS_HOME>/server/all). All you need to do is start the server with this configuration.
-<screen><command><JBOSS_HOME>/bin/./run.sh -c all</command></screen>
-All required jars will be on the classpath. Otherwise, you will need to ensure jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like <filename>JdbmCacheLoader</filename>. The simplest way to do this is to copy the jars from the JBoss Cache distribution's <filename>lib</filename> directory to the server configurations <emphasis>all</emphasis> <filename>lib</filename> directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR. </para>
+<screen>
+$JBOSS_HOME/bin/./run.sh -c all
+</screen>
+<para>
+ All required JARs will be on the classpath. Otherwise, you will need to ensure <filename>jbosscache.jar</filename> and <filename>jgroups-all.jar</filename> are on the classpath. You may need to add other JARs if you are using things like <classname>JdbmCacheLoader</classname>. The simplest way to do this is to copy the jars from the JBoss Cache distribution's <filename>lib</filename> directory to the <filename>lib</filename> directory of your <literal>all</literal> configuration. You could also package the JARs with the configuration file in a Service Archive (SAR) file or an EAR. </para>
<!--<para>It is possible to deploy a JBoss Cache 2.0 instance in JBoss Enterprise Web Platform 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.) </para>-->
- <para>Note in the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file</ulink> the value of the mbean element's code attribute: org.jboss.cache.jmx.CacheJmxWrapper . This is the class JBoss Cache uses to handle JMX integration; the Cache itself does not expose an MBean interface. See the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans">JBoss Cache MBeans section</ulink> for more on the CacheJmxWrapper . </para>
- <para>Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache: </para>
+ <para>
+ Note in <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file</ulink> the value of the mbean element's code attribute: <classname>org.jboss.cache.jmx.CacheJmxWrapper</classname>. This is the class JBoss Cache uses to handle JMX integration; the Cache itself does not expose an MBean interface. See the JBoss Cache MBeans documentation (<ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans</ulink>) for more information about the <classname>CacheJmxWrapper</classname>.
+ </para>
+ <para>
+ Once your cache is deployed, you can use a JMX proxy to obtain a reference to the cache to use it with an in-VM client such as a Servlet, like so:
+ </para>
<para>
-<programlisting><![CDATA[MBeanServer server = MBeanServerLocator.locateJBoss();
+<programlisting><![CDATA[
+MBeanServer server = MBeanServerLocator.locateJBoss();
ObjectName on = new ObjectName("jboss.cache:service=Cache");
-CacheJmxWrapperMBean cacheWrapper =
-
- (CacheJmxWrapperMBean) MBeanServerInvocationHandler.newProxyInstance(server, on,
- CacheJmxWrapperMBean.class, false);
-
- Cache cache = cacheWrapper.getCache();
-
- Node root = cache.getRoot(); // etc etc]]></programlisting>
+CacheJmxWrapperMBean cacheWrapper = (CacheJmxWrapperMBean)
+MBeanServerInvocationHandler.newProxyInstance(server, on,
+CacheJmxWrapperMBean.class, false);
+
+Cache cache = cacheWrapper.getCache();
+
+Node root = cache.getRoot(); // etc etc
+ ]]></programlisting>
</para>
- <para>The MBeanServerLocator class is a helper to find the (only) JBoss MBean server inside the current JVM. The javax.management.MBeanServerInvocationHandler class' newProxyInstance method creates a dynamic proxy implementing the given interface and uses JMX to dynamically dispatch methods invoked against the generated interface to the MBean. The name used to look up the MBean is the same as defined in the cache's configuration file. </para>
- <para>Once the proxy to the CacheJmxWrapper is obtained, the getCache() will return a reference to the Cache itself. </para>
+ <para>
+ The <classname>MBeanServerLocator</classname> class locates the JBoss MBean server inside the current JVM. The <methodname>newProxyInstance</methodname> method of the <classname>javax.management.MBeanServerInvocationHandler</classname> class creates a dynamic proxy implementing the given interface and uses JMX to dynamically dispatch methods invoked against the generated interface to the MBean. The name used to look up the MBean is the same name that is defined in the cache's configuration file.
+ </para>
+ <para>
+ Once the proxy to the <classname>CacheJmxWrapper</classname> is obtained, the <methodname>getCache()</methodname> method will return a reference to the Cache itself.
+ </para>
</section>
<section id="pojocachedeployment"><title>Pojo Cache Deployment Options</title>
<para>
There are a number of ways to deploy POJO Cache:
</para>
- <section><title>Programatic Deployment</title>
+ <section><title>Programmatic Deployment</title>
<para>
- Simply instantiate a PojoCacheFactory and invoke one of the overloaded createCache methods shown in the API Overview.
+ Simply instantiate a <classname>PojoCacheFactory</classname> and invoke one of the overloaded <methodname>createCache</methodname> methods shown in the API Overview.
</para>
</section>
- <section><title>JMX-Based Deployment in JBoss Enterprise Web Platform (JBoss Enterprise Web Platform 5.x and 4.x)</title>
+ <section>
+ <title>JMX-Based Deployment in JBoss Enterprise Web Platform</title>
<para>
- If PojoCache is run in JBoss Enterprise Web Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss Enterprise Web Platform MBean deployment descriptor, so the Enterprise Web Platform's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
+ If Pojo Cache is run in JBoss Enterprise Web Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's <filename>deploy</filename> directory. The standard format of Pojo Cache's standard XML configuration file is the same as a JBoss Enterprise Web Platform MBean deployment descriptor, so the Enterprise Web Platform's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in <filename>deploy</filename>; you can package it along with other services or JEE components in a SAR or EAR.
</para>
<para>
- In Enterprise Web Platform 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
+ In Enterprise Web Platform 5, if you're using a server configuration based on the standard <literal>all</literal> config, then that's all you need to do; all required JARs will be on the classpath. Otherwise, you will need to ensure that <filename>pojocache.jar</filename>, <filename>jbosscache.jar</filename> and <filename>jgroups-all.jar</filename> are on the classpath. You may need to add other JARs if you are using things like <classname>JdbmCacheLoader</classname>. The simplest way to do this is to copy the JARs from the Pojo Cache distribution's <filename>lib</filename> directory to the server configuration's <filename>lib</filename> directory. You could also package the JARs with the configuration file in Service Archive (SAR) file or an EAR.
</para>
<!-- <para>
It is possible, to deploy a POJO Cache 2.0 instance in JBoss Enterprise Web Platform 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard Enterprise Web Platform 4.x clustering services (for example, http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in Enterprise Web Platform 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
</para> -->
<para>
- Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
+ Note the value of the MBean element's code attribute in the example: <classname>org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper</classname>. This is the class JBoss Cache uses to handle JMX integration; the Pojo Cache itself does not expose an MBean interface. See the <!--hajime-->JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
</para>
<para>
Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache:
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -3,13 +3,13 @@
<chapter id="clustering-blocks.chapt">
<title>Clustering Building Blocks</title>
- <para>The clustering features in JBoss Enterprise Application Platform are built on top of lower level
+ <para>The clustering features in JBoss Enterprise Web Platform are built on top of lower level
libraries that provide much of the core functionality. <xref linkend="clustering-as-arch.fig"/>
shows the main pieces:
</para>
<figure id="clustering-as-arch.fig">
- <title>The JBoss Enterprise Application Platform clustering architecture</title>
+ <title>The JBoss Enterprise Web Platform clustering architecture</title>
<mediaobject>
<imageobject><!--replace with https://engineering.redhat.com/rt3/Ticket/Display.html?id=55884-->
<imagedata align="center" fileref="images/clustering-as-arch.png" />
@@ -17,26 +17,24 @@
</mediaobject>
</figure>
- <para><emphasis role="bold">JGroups</emphasis> is a toolkit for reliable
+ <para><application>JGroups</application> is a toolkit for reliable
point-to-point and point-to-multipoint communication. JGroups is used for
- all clustering-related communications between nodes in a JBoss Enterprise Application Platform cluster.
- <!-- See <xref linkend="clustering-blocks-jgroups"/> for more on how JBoss Enterprise Application Platform
+ all clustering-related communications between nodes in a JBoss Enterprise Web Platform cluster.
+ <!-- See <xref linkend="clustering-blocks-jgroups"/> for more on how JBoss Enterprise Web Platform
uses JGroups.--></para>
- <para><emphasis role="bold">JBoss Cache</emphasis> is a highly flexible
- clustered transactional caching library. Many Enterprise Application Platform clustering services
- need to cache some state in memory while (1) ensuring for high availability
- purposes that a backup copy of that state is available on another node
- if it can't otherwise be recreated (e.g. the contents of a web session)
- and (2) ensuring that the data cached on each node in the cluster is consistent.
- JBoss Cache handles these concerns for most JBoss Enterprise Application Platform clustered services.
+ <para><application>JBoss Cache</application> is a highly flexible
+ clustered transactional caching library. Many Enterprise Web Platform clustering services
+ need to cache some state in memory while ensuring that a backup of that state is available on
+ another node, and the data cached on each node in the cluster is consistent.
+ JBoss Cache handles these concerns for most JBoss Enterprise Web Platform clustered services.
JBoss Cache uses JGroups to handle its group communication requirements.
- <emphasis role="bold">POJO Cache</emphasis> is an extension of the
- core JBoss Cache that JBoss Enterprise Application Platform uses to support fine-grained replication
+ <application>Pojo Cache</application> is an extension of the
+ core JBoss Cache that JBoss Enterprise Web Platform uses to support fine-grained replication
of clustered web session state. See <xref linkend="clustering-blocks-jbc"/>
- for more on how JBoss Enterprise Application Platform uses JBoss Cache and POJO Cache.</para>
+ for more on how JBoss Enterprise Web Platform uses JBoss Cache and POJO Cache.</para>
- <para><emphasis role="bold">HAPartition</emphasis> is an adapter on top
+ <para><application>HAPartition</application> is an adapter on top
of a JGroups channel that allows multiple services to use the channel.
HAPartition also supports a distributed registry of which HAPartition-based
services are running on which cluster members. It provides notifications to
@@ -52,111 +50,121 @@
<section id="clustering-blocks-jgroups">
<title>Group Communication with JGroups</title>
<para>
- JGroups provides the underlying group communication support for JBoss Enterprise Application Platform clusters. Services deployed on JBoss Enterprise Application Platform which need group communication with their peers will obtain a JGroups <literal>Channel</literal> and use it to communicate. The <literal>Channel</literal> handles such tasks as managing which nodes are members of the group, detecting node failures, ensuring lossless, first-in-first-out delivery of messages to all group members, and providing flow control to ensure fast message senders cannot overwhelm slow message receivers.
+ JGroups provides the underlying group communication support for JBoss Enterprise Web Platform clusters. Services deployed on JBoss Enterprise Web Platform which need group communication with their peers will obtain a JGroups <classname>Channel</classname> and use it to communicate. The <classname>Channel</classname> handles such tasks as managing which nodes are members of the group, detecting node failures, ensuring lossless, first-in-first-out delivery of messages to all group members, and providing flow control to ensure fast message senders cannot overwhelm slow message receivers.
</para>
<para>
- The characteristics of a JGroups <literal>Channel</literal> are determined by the set of <emphasis>protocols</emphasis> that compose it. Each protocol handles a single aspect of the overall group communication task; for example the <literal>UDP</literal> protocol handles the details of sending and receiving UDP datagrams. A <literal>Channel</literal> that uses the <literal>UDP</literal> protocol is capable of communicating with UDP unicast and multicast; alternatively one that uses the <literal>TCP</literal> protocol uses TCP unicast for all messages. JGroups supports a wide variety of different protocols (see <xref linkend="jgroups-configuration"/> for details), but the Enterprise Application Platform ships with a default set of channel configurations that should meet most needs.
+ The characteristics of a JGroups <classname>Channel</classname> are determined by the set of <emphasis>protocols</emphasis> that compose it. Each protocol handles a single aspect of the overall group communication task; for example the <literal>UDP</literal> protocol handles the details of sending and receiving UDP datagrams. A <classname>Channel</classname> that uses the <literal>UDP</literal> protocol is capable of communicating with UDP unicast and multicast; alternatively one that uses the <literal>TCP</literal> protocol uses TCP unicast for all messages. JGroups supports a wide variety of different protocols (see <xref linkend="jgroups-configuration"/> for details), but the Enterprise Web Platform ships with a default set of channel configurations that should meet most needs.
</para>
<para>
- By default, UDP multicast is used by all JGroups channels used by the Enterprise Application Platform (except for one TCP-based channel used by JBoss Messaging).
+ By default, UDP multicast is used by all JGroups channels used by the Enterprise Web Platform, except for a single TCP-based channel used by JBoss Messaging.
</para>
<section id="clustering-blocks-jgroups-channelfactory">
<title>The Channel Factory Service</title>
<para>
- A significant difference in JBoss Enterprise Application Platform 5 versus previous releases is that JGroups Channels needed by clustering services (for example, a channel used by a distributed HttpSession cache) are no longer configured in detail as part of the consuming service's configuration, and are no longer directly instantiated by the consuming service. Instead, a new <literal>ChannelFactory</literal> service is used as a registry for named channel configurations and as a factory for <literal>Channel</literal> instances. A service that needs a channel requests the channel from the <literal>ChannelFactory</literal>, passing in the name of the desired configuration.
+ A significant difference in JBoss Enterprise Web Platform 5 compared to previous releases is that the JGroups channels needed by clustering services (for example, a channel used by a distributed <classname>HttpSession</classname> cache) are no longer configured in detail as part of the consuming service's configuration, and are no longer directly instantiated by the consuming service. Instead, a new <classname>ChannelFactory</classname> service is used as a registry for named channel configurations and as a factory for <classname>Channel</classname> instances. A service that needs a channel requests the channel from the <classname>ChannelFactory</classname>, passing in the name of the desired configuration.
</para>
<para>
- The ChannelFactory service is deployed in the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar</literal>. On startup the ChannelFactory service parses the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file, which includes various standard JGroups configurations identified by name (for example, UDP or TCP). Services needing a channel access the channel factory and ask for a channel with a particular named configuration.
+ The <classname>ChannelFactory</classname> service is deployed in the <filename>server/$PROFILE/deploy/cluster/jgroups-channelfactory.sar</filename>. On startup the ChannelFactory service parses the <filename>server/$PROFILE/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename> file, which includes various standard JGroups configurations identified by name (for example, UDP or TCP). Services that require a channel access the channel factory and request a channel with a particular named configuration.
</para>
<note>
<para>
- If several services request a channel with the same configuration name from the ChannelFactory, they are not handed a reference to the same underlying Channel. Each receives its own Channel, but the channels will have an identical configuration. A logical question is how those channels avoid forming a group with each other if each, for example, is using the same multicast address and port. The answer is that when a consuming service connects its Channel, it passes a unique-to-that-service <literal>cluster_name</literal> argument to the <literal>Channel.connect(String cluster_name)</literal> method. The Channel uses that <literal>cluster_name</literal> as one of the factors that determine whether a particular message received over the network is intended for it.
+ If several services request a channel with the same configuration name from the <classname>ChannelFactory</classname>, they are not handed a reference to the same underlying <classname>Channel</classname>. Each receives its own <classname>Channel</classname>, but the channels will have an identical configuration. A logical question is how those channels avoid forming a group with each other if each, for example, is using the same multicast address and port. The answer is that when a consuming service connects its <classname>Channel</classname>, it passes a unique-to-that-service <varname>cluster_name</varname> argument to the <methodname>Channel.connect(String cluster_name)</methodname> method. The channel uses that <varname>cluster_name</varname> as one of the factors that determine whether a particular message received over the network is intended for that particular channel.
</para>
</note>
- <section id="clustering-blocks-jgroups-stdconfigs">
- <title>Standard Protocol Stack Configurations</title>
- <para>
- The standard protocol stack configurations that ship with Enterprise Application Platform 5 are described below. Note that not all of these are actually used; many are included as a convenience to users who may wish to alter the default server configuration. The configurations actually used in a stock Enterprise Application Platform 5 <emphasis role="bold">all</emphasis> configuration are <literal>udp</literal>, <literal>jbm-control</literal> and <literal>jbm-data</literal>, with all clustering services other than JBoss Messaging using <literal>udp</literal>.
+ <section id="clustering-blocks-jgroups-stdconfigs">
+ <title>Standard Protocol Stack Configurations</title>
+ <para>
+ The standard protocol stack configurations that ship with Enterprise Web Platform 5 are described below. Note that not all of these are actually used; many are included as a convenience to users who may wish to alter the default server configuration profile. The configurations used in a stock Enterprise Web Platform 5 <literal>all</literal> configuration are <literal>udp</literal>, <literal>jbm-control</literal> and <literal>jbm-data</literal>, with all clustering services other than JBoss Messaging using <literal>udp</literal>.
</para>
<para>
- You can add a new stack configuration by adding a new <literal>stack</literal> element to the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file. You can alter the behavior of an existing configuration by editing this file. Before doing this though, have a look at the other standard configurations the Enterprise Application Platform ships; perhaps one of those meets your needs. Also, please note that before editing a configuration you should understand what services are using that configuration; make sure the change you are making is appropriate for all affected services. If the change isn't appropriate for a particular service, perhaps its better to create a new configuration and change some services to use that new configuration.
- </para>
+ You can add a new stack configuration by adding a new <literal>stack</literal> element to the <filename>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename> file. You can alter the behavior of an existing configuration by editing this file. Before doing this though, see the other standard configurations shipped with the Enterprise Web Platform to determine whether they will meet your requirements.
+ </para>
+ <important>
+ <para>
+ Before you edit a configuration, you should understand which services use that configuration. It is important that any changes you make are appropriate for all affected services. If the change is not appropriate for a particular service, it may be better to create a new configuration and alter some services to use the new configuration.
+ </para>
+ </important>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">udp</emphasis></para>
- <para>
- UDP multicast based stack meant to be shared between different channels. Message bundling is disabled, as it can add latency to synchronous group RPCs. Services that only make asynchronous RPCs (for example, JBoss Cache configured for REPL_ASYNC) and do so in high volume may be able to improve performance by configuring their cache to use the <literal>udp-async</literal> stack below. Services that only make synchronous RPCs (for example JBoss Cache configured for REPL_SYNC or INVALIDATION_SYNC) may be able to improve performance by using the <literal>udp-sync</literal> stack below, which does not include flow control.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">udp-async</emphasis></para>
- <para>
- Same as the default <literal>udp</literal> stack above, except message bundling is enabled in the transport protocol (<literal>enable_bundling=true</literal>). Useful for services that make high-volume asynchronous RPCs (e.g. high volume JBoss Cache instances configured for REPL_ASYNC) where message bundling may improve performance.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">udp-sync</emphasis></para>
- <para>
- UDP multicast based stack, without flow control and without message bundling. This can be used instead of <literal>udp</literal> if (1) synchronous calls are used and (2) the message volume (rate and size) is not that large. Don't use this configuration if you send messages at a high sustained rate, or you might run out of memory.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">tcp</emphasis></para>
- <para>
- TCP based stack, with flow control and message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (e.g. routers discard multicast).
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">tcp-sync</emphasis></para>
- <para>
- TCP based stack, without flow control and without message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (e.g.routers discard multicast). This configuration should be used instead of <literal>tcp</literal> above when (1) synchronous calls are used and (2) the message volume (rate and size) is not that large. Don't use this configuration if you send messages at a high sustained rate, or you might run out of memory.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">jbm-control</emphasis>
- </para>
- <para>
- Stack optimized for the JBoss Messaging Control Channel. By default uses the same UDP transport protocol configuration as is used for the default <literal>udp</literal> stack defined above. This allows the JBoss Messaging Control Channel to use the same sockets, network buffers and thread pools as are used by the other standard JBoss Enterprise Application Platform clustered services (see <xref linkend="clustering-blocks-jgroups-sharedtransport"/>)
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">jbm-data</emphasis>
- </para>
- <para>
- TCP-based stack optimized for the JBoss Messaging Data Channel.
- </para>
- </listitem>
- </itemizedlist>
+ <variablelist>
+ <varlistentry>
+ <term><literal>udp</literal></term>
+ <listitem>
+ <para>
+ UDP multicast based stack meant to be shared between different channels. Message bundling is disabled, as it can add latency to synchronous group remote procedure calls (RPCs). Services that only make asynchronous RPCs (for example, JBoss Cache configured for <literal>REPL_ASYNC</literal>) and do so in high volume may be able to improve performance by configuring their cache to use the <literal>udp-async</literal> stack below. Services that only make synchronous RPCs (for example, JBoss Cache configured for <literal>REPL_SYNC</literal> or <literal>INVALIDATION_SYNC</literal>) may be able to improve performance by using the <literal>udp-sync</literal> stack below, which does not include flow control.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>udp-async</literal></term>
+ <listitem>
+ <para>
+ Same as the default <literal>udp</literal> stack above, except message bundling is enabled in the transport protocol (<code>enable_bundling=true</code>). Useful for services that make high-volume asynchronous RPCs (for example, high volume JBoss Cache instances configured for <literal>REPL_ASYNC</literal>) where message bundling may improve performance.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>udp-sync</literal></term>
+ <listitem>
+ <para>
+ UDP multicast based stack, without flow control and without message bundling. This can be used instead of <literal>udp</literal> if synchronous calls are used and the message volume (rate and size) is not very large. Do not use this configuration if you send messages at a high sustained rate, or you might run out of memory.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>tcp</literal></term>
+ <listitem>
+ <para>
+ TCP based stack, with flow control and message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (for example, when routers discard multicast).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>tcp-sync</literal></term>
+ <listitem>
+ <para>
+ TCP based stack, without flow control and without message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (for example, when routers discard multicast). This configuration should be used instead of <literal>tcp</literal> above when synchronous calls are used and the message volume (rate and size) is not very large. Do not use this configuration if you send messages at a high sustained rate, or you might run out of memory.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>jbm-control</literal></term>
+ <listitem>
+ <para>
+ Stack optimized for the JBoss Messaging Control Channel. By default uses the same UDP transport protocol configuration as is used for the default <literal>udp</literal> stack defined above. This allows the JBoss Messaging Control Channel to use the same sockets, network buffers and thread pools as are used by the other standard JBoss Enterprise Web Platform clustered services (see <xref linkend="clustering-blocks-jgroups-sharedtransport"/>).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>jbm-data</literal></term>
+ <listitem>
+ <para>
+ TCP-based stack optimized for the JBoss Messaging Data Channel.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
</section>
-
+<!--hajime-->
<section id="clustering-blocks-jgroups-sharedtransport">
<title>The JGroups Shared Transport</title>
<para>As the number of JGroups-based clustering services running in
- the Enterprise Application Platform has risen over the years, the need to share the resources
+ the Enterprise Web Platform has risen over the years, the need to share the resources
(particularly sockets and threads) used by these channels became
- a glaring problem. A stock Enterprise Application Platform 5 <emphasis role="bold">all</emphasis>
- configuration will connect 4 JGroups channels during startup, and a total of
- 7 or 8 will be connected if distributable web apps, clustered EJB3
- SFSBs and a clustered JPA/Hibernate second level cache are all used.
- So many channels can consume a lot of resources, and can be a real
+ a glaring problem. A pristine Enterprise Web Platform 5 <literal>all</literal>
+ configuration will connect four JGroups channels during startup, and a total of
+ seven or eight will be connected if distributable web applications, clustered EJB3
+ SFSBs and a clustered JPA or Hibernate second level cache are all used.
+ This many channels can consume a lot of resources, and can be a real
configuration nightmare if the network environment requires
configuration to ensure cluster isolation.</para>
- <para>Beginning with Enterprise Application Platform 5, JGroups supports sharing of transport
+ <para>Beginning with Enterprise Web Platform 5, JGroups supports sharing of transport
protocol instances between channels. A JGroups channel is composed of
a stack of individual protocols, each of which is responsible for
one aspect of the channel's behavior. A transport protocol is a
@@ -168,10 +176,10 @@
<para>
To configure a transport protocol for sharing, simply add a
- <literal>singleton_name="someName"</literal> attribute to the protocol's
+ <code>singleton_name="someName"</code> attribute to the protocol's
configuration. All channels whose transport protocol configuration uses the
- same <literal>singleton_name</literal> value will share their transport.
- All other protocols in the stack will not be shared. <xref linkend="clustering-blocks-jgroups-sharedtp.fig"/> illustrates 4 services running in a JVM, each with its own channel.
+ same <varname>singleton_name</varname> value will share their transport.
+ All other protocols in the stack will not be shared. <xref linkend="clustering-blocks-jgroups-sharedtp.fig"/> illustrates four services running in a JVM, each with its own channel.
Three of the services are sharing a transport; the fourth is using
its own transport.</para>
@@ -186,12 +194,12 @@
</mediaobject>
</figure>
- <para>The protocol stack configurations used by the Enterprise Application Platform 5 ChannelFactory
- all have a <literal>singleton_name</literal> configured. In fact, if you add a stack to the
- ChannelFactory that doesn't include a <literal>singleton_name</literal>,
- before creating any channels for that stack, the ChannelFactory will
- synthetically create a <literal>singleton_name</literal> by concatenating
- the stack name to the string "unnamed_", e.g. unnamed_customStack.</para>
+ <para>The protocol stack configurations used by the Enterprise Web Platform 5 <classname>ChannelFactory</classname>
+ all have a <varname>singleton_name</varname> configured. In fact, if you add a stack to the
+ <classname>ChannelFactory</classname> that doesn't include a <varname>singleton_name</varname>,
+ before creating any channels for that stack, the <classname>ChannelFactory</classname> will
+ synthetically create a <varname>singleton_name</varname> by concatenating
+ the stack name to the string <literal>unnamed_</literal>, for example, <literal>unnamed_customStack</literal>.</para>
</section>
</section>
<section id="clustering-blocks-jbc">
@@ -200,9 +208,9 @@
JBoss Cache is a fully featured distributed cache framework that can be
used in any application server environment or standalone. JBoss Cache
provides the underlying distributed caching support used by many of the
- standard clustered services in a JBoss Enterprise Application Platform cluster, including:
+ standard clustered services in a JBoss Enterprise Web Platform cluster, including:
<itemizedlist>
- <listitem><para>replication of clustered webapp sessions</para></listitem>
+ <listitem><para>replication of clustered web application sessions</para></listitem>
<listitem><para>replication of clustered EJB3 Stateful Session beans</para></listitem>
<listitem><para>clustered caching of JPA and Hibernate entities</para></listitem>
<listitem><para>clustered Single Sign-On</para></listitem>
@@ -216,14 +224,15 @@
<xref linkend="jbosscache.chapt"/> for more on this.</para>
<section id="clustering-blocks-jbc-cachemanager">
- <title>The JBoss Enterprise Application Platform CacheManager Service</title>
- <para>Many of the standard clustered services in JBoss Enterprise Application Platform use JBoss
- Cache to maintain consistent state across the cluster. Different
- services (e.g. web session clustering or second level caching of
+ <title>The JBoss Enterprise Web Platform CacheManager Service</title>
+ <para>Many of the standard clustered services in JBoss Enterprise Web Platform use JBoss
+ Cache to maintain consistent state across the cluster. Different
+ services (for example, web session clustering or second level caching of
JPA/Hibernate entities) use different JBoss Cache instances, with
each cache configured to meet the needs of the service that uses it.
- In JBoss Enterprise Application Platform 4, each of these caches was independently deployed in the
- <literal>deploy/</literal> directory, which had a number of disadvantages:
+ Previously, each of these caches was independently deployed in <filename>deploy</filename>
+ directory, which had a number of disadvantages:
+ </para>
<itemizedlist>
<listitem><para>Caches that end user applications
didn't need were deployed anyway, with each creating an expensive
@@ -231,188 +240,232 @@
SFSBs, a cache to store them was started.</para></listitem>
<listitem><para>Caches are internal details of the services that
use them. They shouldn't be first-class deployments.</para></listitem>
- <listitem><para>Services would find their cache via JMX lookups.
- Using JMX for purposes other exposing management interfaces is just
- not the JBoss Enterprise Application Platform 5 way.</para></listitem>
+ <listitem><para>Services would find their cache via JMX lookups. This
+ is not the purpose for which JMX is intended.</para></listitem>
</itemizedlist>
- </para>
- <para>In JBoss Enterprise Application Platform 5, the scattered cache deployments have been replaced
- with a new <emphasis role="bold">CacheManager</emphasis> service,
- deployed via the <literal>JBOSS_HOME/server/all/deploy/cluster/jboss-cache-manager.sar</literal>.
- The CacheManager is a factory and registry for JBoss Cache instances.
+ <para>In JBoss Enterprise Web Platform 5, the scattered cache deployments have been replaced
+ with a new <classname>CacheManager</classname> service,
+ deployed via the <filename>$JBOSS_HOME/server/$PROFILE/deploy/cluster/jboss-cache-manager.sar</filename>.
+ The <classname>CacheManager</classname> is a factory and registry for JBoss Cache instances.
It is configured with a set of named JBoss Cache configurations.
- Services that need a cache ask the cache manager for the cache by
- name; the cache manager creates the cache (if not already created)
- and returns it. The cache manager keeps a reference to each cache
+ Services that require a cache request it by name from the cache manager.
+ The cache manager creates the cache if it does not exist already,
+ and returns it. The cache manager keeps a reference to each cache
it has created, so all services that request the same cache configuration
name will share the same cache. When a service is done with the cache,
- it releases it to the cache manager. The cache manager keeps track
+ it releases it to the cache manager. The cache manager keeps track
of how many services are using each cache, and will stop and destroy
the cache when all services have released it.</para>
<section id="clustering-blocks-jbc-cachemanager-stdconfigs">
<title>Standard Cache Configurations</title>
- <para>The following standard JBoss Cache configurations ship with JBoss Enterprise Application Platform 5.
+ <para>The following standard JBoss Cache configurations ship with JBoss Enterprise Web Platform 5.
You can add others to suit your needs, or edit these configurations
to adjust cache behavior. Additions or changes are done by editing
- the <literal>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</literal>
+ the <filename>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</filename>
file (see <xref linkend="jbosscache-custom-deployment-cachemgr"/>
for details). Note however that these configurations are specifically
optimized for their intended use, and except as specifically noted
in the documentation chapters for each service in this guide,
it is not advisable to change them.</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">standard-session-cache</emphasis></para>
- <para>Standard cache used for web sessions.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">field-granularity-session-cache</emphasis></para>
- <para>Standard cache used for FIELD granularity web sessions.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">sfsb-cache</emphasis></para>
- <para>Standard cache used for EJB3 SFSB caching.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">ha-partition</emphasis></para>
- <para>Used by web tier Clustered Single Sign-On,
- HA-JNDI, Distributed State.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">mvcc-entity</emphasis></para>
- <para>A configuration appropriate for JPA/Hibernate entity/collection
- caching that uses JBC's MVCC locking (see notes below).</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">optimistic-entity</emphasis></para>
- <para>A configuration appropriate for JPA/Hibernate entity/collection
+
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>standard-session-cache</literal></term>
+ <listitem>
+ <para>
+ Standard cache used for web sessions.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>field-granularity-session-cache</literal></term>
+ <listitem>
+ <para>
+ Standard cache used for FIELD granularity web sessions.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>sfsb-cache</literal></term>
+ <listitem>
+ <para>
+ Standard cache used for EJB3 SFSB caching.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>ha-partition</literal></term>
+ <listitem>
+ <para>
+ Used by web tier Clustered Single Sign-On,
+ HA-JNDI, Distributed State.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>mvcc-entity</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for JPA/Hibernate entity/collection
+ caching that uses JBC's MVCC locking (see notes below).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>optimistic-entity</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for JPA/Hibernate entity/collection
caching that uses JBC's optimistic locking (see notes below).
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">pessimistic-entity</emphasis></para>
- <para>A configuration appropriate for JPA/Hibernate entity/collection
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>pessimistic-entity</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for JPA/Hibernate entity/collection
caching that uses JBC's pessimistic locking (see notes below).
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">mvcc-entity-repeatable</emphasis></para>
- <para>Same as "mvcc-entity" but uses JBC's REPEATABLE_READ
- isolation level instead of READ_COMMITTED (see notes below).
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">pessimistic-entity-repeatable</emphasis></para>
- <para>Same as "pessimistic-entity" but uses JBC's REPEATABLE_READ
- isolation level instead of READ_COMMITTED (see notes below).
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">local-query</emphasis></para>
- <para>A configuration appropriate for JPA/Hibernate query result caching.
- Does not replicate query results. DO NOT store the timestamp data
- Hibernate uses to verify validity of query results in this cache.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">replicated-query</emphasis></para>
- <para>A configuration appropriate for JPA/Hibernate query result caching.
- Replicates query results. DO NOT store the timestamp data
- Hibernate uses to verify validity of query result in this cache.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">timestamps-cache</emphasis></para>
- <para>A configuration appropriate for the timestamp data cached as part
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>mvcc-entity-repeatable</literal></term>
+ <listitem>
+ <para>
+ Same as <literal>mvcc-entity</literal> but uses JBC's
+ <literal>REPEATABLE_READ</literal> isolation level
+ instead of <literal>READ_COMMITTED</literal> (see notes below).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>pessimistic-entity-repeatable</literal></term>
+ <listitem>
+ <para>
+ Same as <literal>pessimistic-entity</literal> but uses JBC's
+ <literal>REPEATABLE_READ</literal> isolation level instead
+ of <literal>READ_COMMITTED</literal> (see notes below).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>local-query</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for JPA/Hibernate query result caching.
+ Does not replicate query results. <emphasis>Do not</emphasis> store
+ the timestamp data Hibernate uses to verify validity of query
+ results in this cache.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>replicated-query</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for JPA/Hibernate query result caching.
+ Replicates query results. DO NOT store the timestamp data
+ Hibernate uses to verify validity of query result in this cache.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>timestamps-cache</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for the timestamp data cached as part
of JPA/Hibernate query result caching. A replicated timestamp cache
is required if query result caching is used, even if the query results
- themselves use a non-replicating cache like <literal>local-query</literal>.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">mvcc-shared</emphasis></para>
- <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
+ themselves use a non-replicating cache like <literal>local-query</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>mvcc-shared</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
- advised configuration, since it requires cache mode REPL_SYNC,
+ advised configuration, since it requires cache mode <literal>REPL_SYNC</literal>,
which is the least efficient mode. Also requires a full state
- transfer at startup, which can be expensive. Maintained for
- backwards compatibility reasons, as a shared cache was the only
- option in JBoss 4. Uses JBC's MVCC locking.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">optimistic-shared</emphasis></para>
- <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
+ transfer at startup, which can be expensive. Retained for backwards
+ compatibility. Uses JBC's MVCC locking.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>optimistic-shared</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
- advised configuration, since it requires cache mode REPL_SYNC,
+ advised configuration, since it requires cache mode <literal>REPL_SYNC</literal>,
which is the least efficient mode. Also requires a full state
- transfer at startup, which can be expensive. Maintained for
- backwards compatibility reasons, as a shared cache was the only
- option in JBoss 4. Uses JBC's optimistic locking.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">pessimistic-shared</emphasis></para>
- <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
+ transfer at startup, which can be expensive. Retained for backwards
+ compatibility. Uses JBC's optimistic locking.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>pessimistic-shared</literal></term>
+ <listitem>
+ <para>
+ A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
- advised configuration, since it requires cache mode REPL_SYNC,
+ advised configuration, since it requires cache mode <literal>REPL_SYNC</literal>,
which is the least efficient mode. Also requires a full state
- transfer at startup, which can be expensive. Maintained for
- backwards compatibility reasons, as a shared cache was the only
- option in JBoss 4. Uses JBC's pessimistic locking.</para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">mvcc-shared-repeatable</emphasis></para>
- <para>Same as "mvcc-shared" but uses JBC's REPEATABLE_READ
- isolation level instead of READ_COMMITTED (see notes below).
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">pessimistic-shared-repeatable</emphasis></para>
- <para>Same as "pessimistic-shared" but uses JBC's REPEATABLE_READ
- isolation level instead of READ_COMMITTED. (see notes below).
- </para>
- </listitem>
-
- </itemizedlist>
+ transfer at startup, which can be expensive. Retained for backwards
+ compatibility. Uses JBC's pessimistic locking.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>mvcc-shared-repeatable</literal></term>
+ <listitem>
+ <para>
+ Same as <literal>mvcc-shared</literal> but uses JBC's <literal>REPEATABLE_READ</literal>
+ isolation level instead of <literal>READ_COMMITTED</literal> (see notes below).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>pessimistic-shared-repeatable</literal></term>
+ <listitem>
+ <para>
+ Same as <literal>pessimistic-shared</literal> but uses JBC's <literal>REPEATABLE_READ </literal>
+ isolation level instead of <literal>READ_COMMITTED</literal> (see notes below).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<note><para>For more on JBoss Cache's locking schemes, see
<xref linkend="jbosscache-configuration-concurrency"/>)</para></note>
- <note><para>For JPA/Hibernate second level caching, REPEATABLE_READ is
- only useful if the application evicts/clears entities from the
- EntityManager/Hibernate Session and then expects to repeatably
- re-read them in the same transaction. Otherwise, the Session's
+ <note><para>For JPA/Hibernate second level caching, <literal>REPEATABLE_READ</literal> is
+ only useful if the application evicts or clears entities from the
+ Hibernate Entity Manager Session and then expects to repeatably
+ re-read them in the same transaction. Otherwise, the session's
internal cache provides a repeatable-read semantic.</para></note>
</section>
<section>
<title>Cache Configuration Aliases</title>
- <para>The CacheManager also supports aliasing of caches; i.e.
+ <para>The <classname>CacheManager</classname> also supports aliasing of caches; that is,
allowing caches registered under one name to be looked up under a
different name. Aliasing is useful for sharing caches between
services whose configuration may specify different cache configuration
names. It's also useful for supporting legacy EJB3 application
- configurations ported over from Enterprise Application Platform 4.</para>
- <para>Aliases can be configured by editing the "CacheManager"
- bean in the <literal>jboss-cache-manager-jboss-beans.xml</literal>
+ configurations.</para>
+ <para>Aliases can be configured by editing the <literal>CacheManager</literal>
+ bean in the <filename>jboss-cache-manager-jboss-beans.xml</filename>
file. The following redacted configuration shows the standard aliases in
- Enterprise Application Platform 5:</para>
+ Enterprise Web Platform 5:</para>
<programlisting><![CDATA[
<bean name="CacheManager" class="org.jboss.ha.cachemanager.CacheManager">
@@ -450,26 +503,25 @@
<section id="clustering-hapartition">
<title>The HAPartition Service</title>
<para>
- HAPartition is a general purpose service used for a variety of tasks
- in Enterprise Application Platform clustering. At its core, it is an abstraction built on top of a JGroups <literal>Channel</literal> that provides support for making/receiving RPC
- invocations on/from one or more cluster members. HAPartition allows
- services that use it to share a single <literal>Channel</literal> and
+ <classname>HAPartition</classname> is a general purpose service used for a variety of tasks
+ in Enterprise Web Platform clustering. At its core, it is an abstraction built on top of a JGroups
+ <classname>Channel</classname> that provides support for making and receiving RPC
+ invocations from one or more cluster members. <classname>HAPartition</classname> allows
+ services that use it to share a single <classname>Channel</classname> and
multiplex RPC invocations over it, eliminating the configuration complexity
- and runtime overhead of having each service create its own <literal>Channel</literal>.
- HAPartition also supports a distributed registry of which clustering services are
+ and runtime overhead of having each service create its own <classname>Channel</classname>.
+ <classname>HAPartition</classname> also supports a distributed registry of which clustering services are
running on which cluster members. It provides notifications to
interested listeners when the cluster membership changes or the
- clustered service registry changes. HAPartition forms the core of many
+ clustered service registry changes. <classname>HAPartition</classname> forms the core of many
of the clustering services we'll be discussing in the rest of this
- guide, including smart client-side clustered proxies, EJB 2 SFSB
+ guide, including smart client-side clustered proxies, EJB2 stateful session bean
replication and entity cache management, farming, HA-JNDI and HA singletons.
- Custom services can also make use of HAPartition.
+ Custom services can also make use of <classname>HAPartition</classname>.
</para>
-
-
- <para>The following snippet shows the <literal>HAPartition</literal> service definition packaged with the standard JBoss Enterprise Application Platform distribution.
- This configuration can be found in the <literal>server/all/deploy/cluster/hapartition-jboss-beans.xml</literal> file.
+ <para>The following snippet shows the <classname>HAPartition</classname> service definition packaged with the standard JBoss Enterprise Web Platform distribution.
+ This configuration can be found in the <filename>server/$PROFILE/deploy/cluster/hapartition-jboss-beans.xml</filename> file.
</para>
<programlisting><![CDATA[
<bean name="HAPartitionCacheHandler" class="org.jboss.ha.framework.server.HAPartitionCacheHandlerImpl">
@@ -515,99 +567,146 @@
</property>
</bean>]]>
</programlisting>
- <para>Much of the above is generic; below we'll touch on the key points relevant to end users. There are two beans defined above, the <literal>HAPartitionCacheHandler</literal> and the <literal>HAPartition</literal> itself.</para>
+ <para>Much of the above is generic. In subsequent sections we will touch on the key points relevant to end users. There are two beans defined above, the <classname>HAPartitionCacheHandler</classname> and the <classname>HAPartition</classname> itself.</para>
- <para>The <literal>HAPartition</literal> bean itself exposes the following configuration properties:</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">partitionName</emphasis> is an optional attribute to specify the
- name of the cluster. Its default value is <literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. --partition) command line switch to set this value at server startup.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">nodeAddress</emphasis> is unused and can be ignored.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">stateTransferTimeout</emphasis> specifies the timeout (in milliseconds) for initial application state transfer. State transfer refers to the process of obtaining a serialized copy of initial application state from other already-running cluster members at service startup. Its default value is <literal>30000</literal>. </para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">methodCallTimeout</emphasis> specifies the timeout (in milliseconds) for obtaining responses to group RPCs from the other cluster members. Its default value is <literal>60000</literal>. </para>
- </listitem>
- </itemizedlist>
+ <para>The <classname>HAPartition</classname> bean itself exposes the following configuration properties:</para>
- <para>The <literal>HAPartitionCacheHandler</literal> is a small utility service that
- helps the HAPartition integrate with JBoss Cache
- (see <xref linkend="clustering-blocks-jbc-cachemanager"/>). HAPartition exposes
- a child service called DistributedState (see <xref linkend="clustering-hapartition-distributedstate"/>)
- that uses JBoss Cache; the <literal>HAPartitionCacheHandler</literal> helps ensure
- consistent configuration between the JGroups <literal>Channel</literal> used by
- Distributed State's cache and the one used directly by HAPartition.</para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>partitionName</varname></term>
+ <listitem>
+ <para>
+ An optional attribute to specify the name of the cluster. Its default
+ value is <literal>DefaultPartition</literal>. Use the <code>-g</code>
+ (or <code>--partition</code>) command line switch to set this value at
+ server startup.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>nodeAddress</varname></term>
+ <listitem>
+ <para>
+ This attribute is not used and can be ignored.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>stateTransferTimeout</varname></term>
+ <listitem>
+ <para>
+ Specifies the timeout in milliseconds for initial application state
+ transfer. State transfer refers to the process of obtaining a serialized
+ copy of initial application state from other already-running cluster
+ members at service startup. Its default value is <literal>30000</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>methodCallTimeout</varname></term>
+ <listitem>
+ <para>
+ Specifies the timeout in milliseconds for obtaining responses to group
+ remote procedure calls from other cluster members. Its default value
+ is <literal>60000</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">cacheConfigName</emphasis> the name of the JBoss Cache configuration to use for the HAPartition-related cache. Indirectly, this also specifies the name of the JGroups protocol stack configuration HAPartition should use. See <xref linkend="jbosscache-configuration-jgroups"/> for more on how the JGroups protocol stack is configured.</para>
- </listitem>
- </itemizedlist>
- <para>In order for nodes to form a cluster, they must have the exact same <literal>partitionName</literal>
- and the <literal>HAPartitionCacheHandler</literal>'s <literal>cacheConfigName</literal>
+ <para>The <classname>HAPartitionCacheHandler</classname> is a small utility service that
+ helps the <classname>HAPartition</classname> integrate with JBoss Cache
+ (see <xref linkend="clustering-blocks-jbc-cachemanager"/>).
+ <classname>HAPartition</classname> exposes a child service called
+ <classname>DistributedState</classname> (see <xref linkend="clustering-hapartition-distributedstate"/>)
+ that uses JBoss Cache; the <classname>HAPartitionCacheHandler</classname> helps ensure
+ consistent configuration between the JGroups <classname>Channel</classname> used by
+ <classname>DistributedState</classname>'s cache and the one used directly
+ by <classname>HAPartition</classname>.</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><varname>cacheConfigName</varname></term>
+ <listitem>
+ <para>
+ The name of the JBoss Cache configuration to use for the
+ <classname>HAPartition</classname>-related cache. Indirectly,
+ this also specifies the name of the JGroups protocol stack
+ configuration HAPartition should use. See <xref linkend="jbosscache-configuration-jgroups"/>
+ for more on how the JGroups protocol stack is configured.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>In order for nodes to form a cluster, they must have the exact same <varname>partitionName</varname>
+ and the <classname>HAPartitionCacheHandler</classname>'s <varname>cacheConfigName</varname>
must specify an identical JBoss Cache configuration. Changes in either
element on some but not all nodes would prevent proper clustering behavior.
</para>
<para>You can view the current cluster information by pointing your browser to the JMX console of any
- JBoss instance in the cluster (i.e., <literal>http://hostname:8080/jmx-console/</literal>) and then
- clicking on the <literal>jboss:service=HAPartition,partition=DefaultPartition</literal> MBean (change the MBean name to reflect your partitionr name if you use the -g startup switch). A list of IP addresses for the current cluster members is shown in the CurrentView field.</para>
+ JBoss instance in the cluster (that is, <literal>http://hostname:8080/jmx-console/</literal>) and then
+ clicking on the <literal>jboss:service=HAPartition,partition=DefaultPartition</literal> MBean (change the MBean name to reflect your partition name if you use the <code>-g</code> startup switch). A list of IP addresses for the current cluster members is shown in the <literal>CurrentView</literal> field.</para>
<note><title>Note</title>
<para>
- While it is technically possible to put a JBoss server instance into multiple HAPartitions at the same time, this practice is generally not recommended, as it increases management complexity.
+ While it is technically possible to put a JBoss server instance into multiple
+ <classname>HAPartition</classname>s at the same time, this practice is generally
+ not recommended, as it increases management complexity.
</para>
</note>
<section id="clustering-hapartition-drm">
<title>DistributedReplicantManager Service</title>
<para>
- The <literal>DistributedReplicantManager</literal> (DRM) service is a component
- of the HAPartition service made available to HAPartition
- users via the <literal>HAPartition.getDistributedReplicantManager()</literal>
- method. Generally speaking, JBoss Enterprise Application Platform users will not directly make
+ The <classname>DistributedReplicantManager</classname> (DRM) service is a component
+ of the <classname>HAPartition</classname> service made available to
+ <classname>HAPartition</classname> users via the
+ <methodname>HAPartition.getDistributedReplicantManager()</methodname>
+ method. Generally speaking, JBoss Enterprise Web Platform users will not directly make
use of the DRM; we discuss it here as an aid to those who want a
- deeper understanding of how Enterprise Application Platform clustering internals work.</para>
+ deeper understanding of how Enterprise Web Platform clustering internals work.</para>
<para>
- The DRM is a distributed registry that allows HAPartition users to
- register objects under a given key, making available to callersthe
- set of objects registered under that key by the various members of t
- he cluster. The DRM also provides a notification mechanism so interested
+ The DRM is a distributed registry that allows <classname>HAPartition</classname> users to
+ register objects under a given key, making the objects registered under that key
+ by various cluster members available to callers.
+ The DRM also provides a notification mechanism so that interested
listeners can be notified when the contents of the registry changes.
</para>
- <para>There are two main usages for the DRM in JBoss Enterprise Application Platform:</para>
+ <para>There are two main uses for the DRM in JBoss Enterprise Web Platform:</para>
- <itemizedlist>
+ <variablelist>
+ <varlistentry>
+ <term><literal>Clustered Smart Proxies</literal></term>
<listitem>
- <para><emphasis role="bold">Clustered Smart Proxies</emphasis></para>
<para>Here the keys are the names of the various services that need a
clustered smart proxy (see <xref linkend="clustering-concepts-arch-proxy"/>,
- e.g. the name of a clustered EJB. The value object each node stores in
- the DRM is known as a "target". It's something a smart proxy's transport
- layer can use to contact the node (e.g. an RMI stub, an HTTP URL or a JBoss Remoting
- <literal>InvokerLocator</literal>). The factory that builds clustered smart
- proxies accesses the DRM to get the set of "targets" that should be
+ for example, the name of a clustered EJB. The value object each node stores in
+ the DRM is known as a <emphasis>target</emphasis>. This is used by the smart proxy's transport
+ layer to contact the node (for example, an RMI stub, an HTTP URL or a JBoss Remoting
+ <classname>InvokerLocator</classname>). The factory that builds clustered smart
+ proxies accesses the DRM to get the set of targets that should be
injected into the proxy to allow it to communicate with all the
nodes in a cluster.</para>
</listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><classname>HASingleton</classname></term>
<listitem>
- <para><emphasis role="bold">HASingleton</emphasis></para>
<para>Here the keys are the names of the various services that need to
- function as High Availablity Singletons (see <!-- <xref linkend="clustering-hasingleton"/> --> the HASingleton chapter).
- The value object each node stores in the DRM is simply a String that
+ function as High Availablity Singletons.
+ The value object each node stores in the DRM is simply a string that
acts as a token to indicate that the node has the service deployed, and
- thus is a candidate to become the "master" node for the HA singleton
+ thus is a candidate to become the "master" node for the <classname>HASingleton</classname>
service.</para>
</listitem>
</itemizedlist>
<para>In both cases, the key under which objects are registered identifies
a particular clustered service. It is useful to understand that every
- node in a cluster doesn't have to register an object under every key.
+ node in a cluster need not register an object under every key.
Only services that are deployed on a particular node will register
something under that service's key, and services don't have to be
deployed homogeneously across the cluster. The DRM is thus useful as a
@@ -618,31 +717,28 @@
<section id="clustering-hapartition-distributedstate">
<title>DistributedState Service</title>
<para>
- The <literal>DistributedState</literal> service is a legacy component
- of the HAPartition service made available to HAPartition
- users via the <literal>HAPartition.getDistributedState()</literal>
+ The <classname>DistributedState</classname> service is a legacy component
+ of the <classname>HAPartition</classname> service made available to HAPartition
+ users via the <methodname>HAPartition.getDistributedState()</methodname>
method. This service provides coordinated management of arbitary
- application state around the cluster. It is supported for backwards
- compatibility reasons, but new applications should not use it; they
- should use the much more sophisticated JBoss Cache instead.
+ application state around the cluster. Support is provided only for backwards
+ compatibility; new applications should use JBoss Cache instead.
</para>
- <para>In JBoss Enterprise Application Platform 5 the <literal>DistributedState</literal> service actually
+ <para>In JBoss Enterprise Web Platform 5 the <classname>DistributedState</classname> service
delegates to an underlying JBoss Cache instance.</para>
</section>
<section id="clustering-hapartition-customsvcs">
<title>Custom Use of HAPartition</title>
- <para>Custom services can also use make use of HAPartition to handle
+ <para>Custom services can also use make use of <classname>HAPartition</classname> to handle
interactions with the cluster. Generally the easiest way to do this
- is to extend the <literal>org.jboss.ha.framework.server.HAServiceImpl</literal>
- base class, or the <literal>org.jboss.ha.jxm.HAServiceMBeanSupport</literal>
+ is to extend the <classname>org.jboss.ha.framework.server.HAServiceImpl</classname>
+ base class, or the <classname>org.jboss.ha.jxm.HAServiceMBeanSupport</classname>
class if JMX registration and notification support are desired.
</para>
</section>
</section>
-
- </chapter>
-
+</chapter>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -13,26 +13,36 @@
<title>Cluster Definition</title>
<para>
A cluster is a set of nodes that communicate with each other and work
- toward a common goal. In a JBoss Enterprise Application Platform cluster (also known
- as a “partition”), a node is an JBoss Enterprise Application Platform instance.
+ toward a common goal. In a JBoss Enterprise Web Platform cluster (also known
+ as a <emphasis>partition</emphasis>), a node is an JBoss Enterprise Web Platform instance.
Communication between the nodes is handled by the JGroups group communication
- library, with a JGroups <literal>Channel</literal> providing the core functionality of tracking
+ library, with a JGroups <classname>Channel</classname> providing the core functionality of tracking
who is in the cluster and reliably exchanging messages between the cluster
- members. JGroups channels with the same configuration and name have the
+ members. JGroups channels with the same configuration and name have the
ability to dynamically discover each other and form a group. This is why
- simply executing “run -c all” on two Enterprise Application Platform instances on the same network is
- enough for them to form a cluster – each Enterprise Application Platform starts a <literal>Channel</literal> (actually,
- several) with the same default configuration, so they dynamically discover
- each other and form a cluster. Nodes can be dynamically added to or removed
- from clusters at any time, simply by starting or stopping a <literal>Channel</literal> with a
+ simply executing <code>run -c all</code> on two Enterprise Web Platform instances on the same network is
+ enough for them to form a cluster — each Enterprise Web Platform
+ starts one or more <classname>Channel</classname>s with the same default
+ configuration, so that they dynamically discover each other and
+ form a cluster. Nodes can be dynamically added to or removed
+ from clusters at any time, simply by starting or stopping a <classname>Channel</classname> with a
configuration and name that matches the other cluster members.
</para>
<para>
- On the same Enterprise Application Platform instance, different services can create their own <literal>Channel</literal>.
- In a standard startup of the Enterprise Application Platform 5 <emphasis>all</emphasis> configuration, two different services create a total of four different channels – JBoss Messaging creates two and a core general purpose clustering service known as HAPartition creates two more. If you deploy clustered web applications, clustered EJB3 SFSBs or a clustered JPA/Hibernate entity cache, additional channels will be created. The channels the Enterprise Application Platform connects can be divided into three broad categories: a general purpose channel used by the HAPartition service, channels created by JBoss Cache for special purpose caching and cluster wide state replication, and two channels used by JBoss Messaging.
+ On the same Enterprise Web Platform instance, different services
+ can create their own <classname>Channel</classname>. In a standard startup
+ of the Enterprise Web Platform 5 <literal>all</literal> configuration,
+ two different services create a total of four different channels —
+ JBoss Messaging creates two, and a core general purpose clustering service
+ known as <classname>HAPartition</classname> creates two more. If you deploy clustered web applications,
+ clustered EJB3 SFSBs or a clustered JPA/Hibernate entity cache, additional
+ channels will be created. The channels the Enterprise Web Platform connects
+ can be divided into three broad categories: a general purpose channel used
+ by the <classname>HAPartition</classname> service, channels created by JBoss Cache for special
+ purpose caching and cluster wide state replication, and two channels used by JBoss Messaging.
</para>
<para>
- So, if you go to two Enterprise Application Platform 5.0.x instances and execute <literal>run -c all</literal>,
+ So, if you go to two Enterprise Web Platform 5 instances and execute <code>run -c all</code>,
the channels will discover each other and you'll have a conceptual
<literal>cluster</literal>. It's easy to think of this as a two node
cluster, but it's important to understand that you really have multiple channels,
@@ -43,8 +53,8 @@
<xref linkend="clustering-Partition.fig"/> shows an example network of JBoss
server instances divided into three sets, with the third set only
having one node. This sort of topology can be set up simply by configuring
- the Enterprise Application Platform instances such that within a set of nodes meant to form a cluster the
- Channel configurations and names match while they differ from any other channel configurations and names match while they differ from any other channels on the same network. The Enterprise Application Platform tries to make this is easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the <literal>-g</literal> (partition name) and <literal>-u</literal> (multicast address) startup switches. For each set of servers, different values should be chosen. The sections on “JGroups Configuration” and “Isolating JGroups Channels” cover in detail how to configure the Enterprise Application Platform such that desired peers find each other and unwanted peers do not.</para>
+ the Enterprise Web Platform instances such that within a set of nodes meant to form a cluster the
+ <classname>Channel</classname> configurations and names match while they differ from any other channel configurations and names match while they differ from any other channels on the same network. The Enterprise Web Platform tries to make this as easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the <code>-g</code> (partition name) and <code>-u</code> (multicast address) startup switches. Different calues should be chosen for each set of servers. <xref linkend="jgroups-configuration"/> and <xref linkend="clustering-jgroups-isolation"/> cover in detail how to configure the Enterprise Web Platform such that desired peers find each other and unwanted peers do not.</para>
<figure id="clustering-Partition.fig">
<title>Clusters and server nodes</title>
<mediaobject>
@@ -55,26 +65,31 @@
</figure>
</section>
+
<section id="clustering-concepts-arch">
<title>Service Architectures</title>
- <para>The clustering topography defined by the JGroups configuration on each node is of great importance to system administrators. But for most application developers, the greater concern is probably the cluster
- architecture from a client application's point of view. Two basic clustering
- architectures are used with JBoss Enterprise Application Platform: client-side interceptors (a.k.a. smart
- proxies or stubs) and external load balancers. Which architecture your
- application will use will depend on what type of client you have.
+ <para>
+ The clustering topography defined by the JGroups configuration on each
+ node is of great importance to system administrators. But for most
+ application developers, the greater concern is probably the cluster
+ architecture from a client application's point of view. Two basic clustering
+ architectures are used with JBoss Enterprise Web Platform:
+ client-side interceptors (also known as smart
+ proxies or <emphasis>stubs</emphasis>) and external load balancers. Which architecture your
+ application will use will depend on what type of client you have.
</para>
<section id="clustering-concepts-arch-proxy">
<title>Client-side interceptor architecture</title>
<para>
- Most remote services provided by the JBoss Enterprise Application Platform, including
+ Most remote services provided by the JBoss Enterprise Web Platform, including
JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain
- (for example, to look up and download) a remote proxy object. The proxy object
+ (that is, to look up and download) a remote proxy object. The proxy object
is generated by the server and it implements the business interface of
the service. The client then makes local method calls against the proxy
object. The proxy automatically routes the call across the network where
- it is invoked against service objects managed in the server. The proxy
+ it is invoked against service objects managed in the server. The proxy
object figures out how to find the appropriate server node, marshal call
parameters, unmarshal call results, and return the result to the caller
client. In a clustered environment, the server-generated proxy object includes an
@@ -86,7 +101,7 @@
<para>The proxy's clustering logic maintains up-to-date knowledge about
the cluster. For instance, it knows the IP addresses of all available
server nodes, the algorithm to distribute load across nodes (see next section),
- and how to failover the request if the target node not available.
+ and how to failover the request if the target node is not available.
As part of handling each service request, if the cluster topology has
changed the server node updates the proxy with the latest changes
in the cluster. For instance, if a node drops out of the cluster, each
@@ -118,12 +133,12 @@
responses directly over the wire using the HTTP protocol). In this
case, an external load balancer is required to process all requests and
dispatch them to server nodes in the cluster. The client only needs to know
- how to contact the load balancer; it has no knowledge of the JBoss Enterprise Application Platform
+ how to contact the load balancer; it has no knowledge of the JBoss Enterprise Web Platform
instances behind the load balancer. The load balancer is logically part
- of the cluster, but we refer to it as “external” because it is not running
- in the same process as either the client or any of the JBoss Enterprise Application Platform instances.
- It can be implemented either in software or hardware. There are many
- vendors of hardware load balancers; the mod_jk Apache module is an excellent
+ of the cluster, but we refer to it as external because it is not running
+ in the same process as either the client or any of the JBoss Enterprise Web Platform instances.
+ It can be implemented either in software or hardware. There are many
+ vendors of hardware load balancers; the <application>mod_jk</application> module is an excellent
example of a software load balancer. An external load balancer implements
its own mechanism for understanding the cluster configuration and provides
its own load balancing and failover policies. The external load balancer
@@ -149,39 +164,48 @@
<section id="clustering-concepts-balancepolicy">
<title>Load Balancing Policies</title>
<para>
- Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine to which server node a new request should be sent. In this section, let's go over the load balancing policies available in JBoss Enterprise Application Platform.
+ Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine which server node should receive a new request. In this section, let's go over the load balancing policies available in JBoss Enterprise Web Platform.
</para>
<section id="clustering-concepts-balancepolicy-30">
<title>Client-side interceptor architecture</title>
<para>
- In JBoss Enterprise Application Platform 5, the following load balancing options are available when the client-side interceptor architecture is used. The client-side stub maintains a list of all nodes providing the target service; the job of the load balance policy is to pick a node from this list for each request. Each policy has two implementation classes, one meant for use by legacy services like EJB2 that use the legacy detached invoker architecture, and the other meant for services like EJB3 that use AOP-based invocations.
+ In JBoss Enterprise Web Platform 5, the following load balancing options are available when the client-side interceptor architecture is used. The client-side stub maintains a list of all nodes providing the target service; the job of the load balance policy is to pick a node from this list for each request. Each policy has two implementation classes, one meant for use by legacy services like EJB2 that use the legacy detached invoker architecture, and the other meant for services like EJB3 that use AOP-based invocations.
</para>
- <itemizedlist>
- <listitem>
- <para>
- Round-Robin: each call is dispatched to a new node, proceeding sequentially through the list of nodes. The first target node is randomly selected from the list. Implemented by <literal>org.jboss.ha.framework.interfaces.RoundRobin</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RoundRobin</literal> (EJB3).
- </para>
- </listitem>
-
- <listitem>
- <para>
- Random-Robin: for each call the target node is randomly selected from the list. Implemented by <literal>org.jboss.ha.framework.interfaces.RandomRobin </literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RandomRobin </literal> (EJB3).
- </para>
- </listitem>
- <listitem>
- <para>
- First Available: one of the available target nodes is elected as the main target and is thereafter used for every call; this elected member is randomly chosen from the list of members in the cluster. When the list of target nodes changes (because a node starts or dies), the policy will choose a new target node unless the currently elected node is still available. Each client-side proxy elects its own target node independently of the other proxies, so if a particular client downloads two proxies for the same target service (for example, an EJB), each proxy will independently pick its target. This is an example of a policy that provides “session affinity” or “sticky sessions”, since the target node does not change once established. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailable</literal> (EJB3).
- </para>
- </listitem>
-
-
- <listitem>
- <para>
- First Available Identical All Proxies: has the same behavior as the "First Available" policy but the elected target node is shared by all proxies in the same client-side VM that are associated with the same target service. So if a particular client downloads two proxies for the same target service (e.g. an EJB), each proxy will use the same target. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies</literal> (EJB3).
- </para>
- </listitem>
-
- </itemizedlist>
+ <variablelist>
+ <varlistentry>
+ <term>Round-Robin</term>
+ <listitem>
+ <para>
+ Each call is dispatched to a new node, proceeding sequentially through the list of nodes. The first target node is randomly selected from the list. Implemented by <classname>org.jboss.ha.framework.interfaces.RoundRobin</classname> (legacy) and <classname>org.jboss.ha.client.loadbalance.RoundRobin</classname> (EJB3).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Random-Robin</term>
+ <listitem>
+ <para>
+ For each call the target node is randomly selected from the list. Implemented by <classname>org.jboss.ha.framework.interfaces.RandomRobin </classname> (legacy) and <classname>org.jboss.ha.client.loadbalance.RandomRobin </classname> (EJB3).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>First Available</term>
+ <listitem>
+ <para>
+ One of the available target nodes is elected as the main target and is thereafter used for every call. This elected member is randomly chosen from the list of members in the cluster. When the list of target nodes changes (because a node starts or dies), the policy will choose a new target node unless the currently elected node is still available. Each client-side proxy elects its own target node independently of the other proxies, so if a particular client downloads two proxies for the same target service (for example, an EJB), each proxy will independently pick its target. This is an example of a policy that provides <emphasis>session affinity</emphasis> or <emphasis>sticky sessions</emphasis>, since the target node does not change once established. Implemented by <classname>org.jboss.ha.framework.interfaces.FirstAvailable</classname> (legacy) and <classname>org.jboss.ha.client.loadbalance.aop.FirstAvailable</classname> (EJB3).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>First Available Identical All Proxies</term>
+ <listitem>
+ <para>
+ Has the same behavior as the "First Available" policy but the elected target node is shared by all proxies in the same client-side VM that are associated with the same target service. So if a particular client downloads two proxies for the same target service (for example, an EJB), each proxy will use the same target. Implemented by <classname>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</classname> (legacy) and <classname>org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies</classname> (EJB3).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
Each of the above is an implementation of the <classname>org.jboss.ha.framework.interfaces.LoadBalancePolicy</classname> interface; users are free to write their own implementation of this simple interface if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services.
</para>
@@ -189,34 +213,38 @@
<section><title>External load balancer architecture</title>
<para>
- New in JBoss Enterprise Application Platform 5 are a set of "TransactionSticky" load balance policies. These extend the standard policies above to add behavior such that all invocations that occur within the scope of a transaction are routed to the same node (if that node still exists). These are based on the legacy detached invoker architecture, so they are not available for AOP-based services like EJB3.
+ New in JBoss Enterprise Web Platform 5 are a set of <literal>TransactionSticky</literal> load balance policies. These extend the standard policies above to add behavior such that all invocations that occur within the scope of a transaction are routed to the same node (if that node still exists). These are based on the legacy detached invoker architecture, so they are not available for AOP-based services like EJB3.
</para>
- <itemizedlist>
- <listitem>
- <para>
- Transaction-Sticky Round-Robin: Transaction-sticky variant of Round-Robin. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyRoundRobin</literal>.
+
+ <variablelist>
+ <varlistentry>
+ <term>Transaction-Sticky Round-Robin</term>
+ <listitem>
+ <para>
+ Transaction-sticky variant of Round-Robin. Implemented by <classname>org.jboss.ha.framework.interfaces.TransactionStickyRoundRobin</classname>.
</para>
- </listitem>
-
- <listitem>
- <para>
- Transaction-Sticky Random-Robin: Transaction-sticky variant of Random-Robin. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyRandomRobin</literal>.
- </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Transaction-Sticky Random-Robin</term>
+ <listitem>
+ <para>
+ Transaction-sticky variant of Random-Robin. Implemented by <classname>org.jboss.ha.framework.interfaces.TransactionStickyRandomRobin</classname>.
+ </para>
</listitem>
- <listitem>
- <para>
- Transaction-Sticky First Available: Transaction-sticky variant of First Available. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailable</literal>.
+ </varlistentry>
+ <varlistentry>
+ <term>Transaction-Sticky First Available</term>
+ <listitem>
+ <para>
+ Transaction-sticky variant of First Available. Implemented by <classname>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailable</classname>.
</para>
</listitem>
-
- <listitem>
- <para>
- Transaction-Sticky First Available Identical All Proxies: Transaction-sticky variant of First Available Identical All Proxies. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailableIdenticalAllProxies</literal>.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Each of the above is an implementation of a simple interface; users are free to write their own implementations if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services.
+ </varlistentry>
+ </variablelist>
+
+ <para>
+Each of the above is an implementation of a simple interface; users are free to write their own implementations if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services.
</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -39,7 +39,7 @@
<section>
<title>HASingleton Deployment Options</title>
<para>
- The JBoss Enterprise Application Platform provides support for a number of
+ The JBoss Enterprise Web Platform provides support for a number of
strategies for helping you deploy clustered singleton services. In
this section we will explore the different strategies. All of the
strategies are built on top of the HAPartition service described
@@ -61,7 +61,7 @@
<literal>deploy-hasingleton</literal> directory does not lie under
<literal>deploy</literal> nor <literal>farm</literal> directories,
so its contents are not automatically deployed
- when an Enterprise Application Platform instance starts. Instead, deploying the contents of this
+ when an Enterprise Web Platform instance starts. Instead, deploying the contents of this
directory is the responsibility of a special service, the
<literal>HASingletonDeployer</literal> bean
(which itself is deployed via the
@@ -310,7 +310,7 @@
}
]]></programlisting>
<para>
- JBoss Enterprise Application Platform ships with two election policies:
+ JBoss Enterprise Web Platform ships with two election policies:
</para>
<variablelist>
<varlistentry>
@@ -363,7 +363,7 @@
</para>
<para>
- Farming is enabled by default in the <literal>all</literal> configuration in JBoss Enterprise Application Platform and thus requires no manual setup.
+ Farming is enabled by default in the <literal>all</literal> configuration in JBoss Enterprise Web Platform and thus requires no manual setup.
The required <filename>farm-deployment-jboss-beans.xml</filename> and <filename>timestamps-jboss-beans.xml</filename> configuration files are located in the <literal>deploy/cluster</literal> directory.
If you want to enable farming in a custom configuration, simply copy these files to the corresponding JBoss deploy directory <literal>$JBOSS_HOME/server/your_own_config/deploy/cluster</literal>.
Make sure that your custom configuration has clustering enabled.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -438,7 +438,7 @@
<para>
Clustering stateful session beans is more complex than clustering their stateless counterparts
since JBoss needs to manage the state information. The state of all stateful session beans are
- replicated and synchronized across the cluster each time the state of a bean changes. The JBoss Enterprise Application Platform
+ replicated and synchronized across the cluster each time the state of a bean changes. The JBoss Enterprise Web Platform
uses the <literal>HASessionStateService</literal> bean to manage distributed session states for clustered
EJB 2.x stateful session beans. In this section, we cover both the session bean configuration and
the <literal>HASessionStateService</literal> bean configuration.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,7 +4,7 @@
<chapter id="clustering-entity">
<title>Clustered Entity EJBs</title>
<para>
- In a JBoss Enterprise Application Platform cluster, entity bean instance caches need to be kept in sync across all nodes.
+ In a JBoss Enterprise Web Platform cluster, entity bean instance caches need to be kept in sync across all nodes.
If an entity bean provides remote services, the service methods need to be load balanced as well.
</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -195,7 +195,7 @@
worker.status.type=status
</programlisting>
<para>Basically, the above file configures mod_jk to perform weighted round-robin load balancing with
- sticky sessions between two servlet containers (that is, JBoss Enterprise Application Platform instances) node1 and node2 listening on port
+ sticky sessions between two servlet containers (that is, JBoss Enterprise Web Platform instances) node1 and node2 listening on port
8009.</para>
<para>In the <literal>workers.properties</literal> file, each node is defined using the
<literal>worker.XXX</literal> naming convention where <literal>XXX</literal> represents an
@@ -225,7 +225,7 @@
</section>
<section id="clustering-http-jboss">
<title>Configuring JBoss to work with mod_jk</title>
- <para>Finally, we must configure the JBoss Enterprise Application Platform instances on all clustered nodes so that they can
+ <para>Finally, we must configure the JBoss Enterprise Web Platform instances on all clustered nodes so that they can
expect requests forwarded from the mod_jk loadbalancer.</para>
<para>On each clustered JBoss node, we have to name the node according to the name specified in
<literal>workers.properties</literal>. For instance, on JBoss instance node1, edit the
@@ -266,7 +266,7 @@
</section>
<section id="clustering-http-state">
<title>Configuring HTTP session state replication</title>
- <para>The preceding discussion has been focused on using mod_jk as a load balancer. The content of the remainder our discussion of clustering HTTP services in JBoss Enterprise Application Platform applies no matter what load balancer is used.
+ <para>The preceding discussion has been focused on using mod_jk as a load balancer. The content of the remainder our discussion of clustering HTTP services in JBoss Enterprise Web Platform applies no matter what load balancer is used.
</para>
<para>In <xref linkend="clustering-http-nodes"/>, we covered how to use sticky sessions to make sure that a client in a session always hits the same server node in order to maintain the session state. However, sticky sessions by themselves are not an ideal solution. If a node goes down, all its session data is lost. A better and more reliable solution is to replicate session data across the nodes in the cluster. This way, if a server node fails or is shut down, the load balancer can fail over the next client request to any server node and obtain the same session state.</para>
@@ -274,11 +274,11 @@
<!--<para>The <literal>jboss.cache:service=TomcatClusteringCache</literal> MBean makes use of JBoss Cache to
provide HTTP session replication services to the JBoss Tomcat cluster. This MBean is defined in the <literal>deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml file</literal>.</para>
<note>
- <para>Before JBoss Enterprise Application Platform 4.2.0, the location of the HTTP session cache configuration file was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Prior to Enterprise Application Platform 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-service.xml</literal>. </para>
+ <para>Before JBoss Enterprise Web Platform 4.2.0, the location of the HTTP session cache configuration file was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Prior to Enterprise Web Platform 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-service.xml</literal>. </para>
</note>
<para>Below is a typical <literal>deploy/jbossweb-cluster.sar/META-INF/jboss-service.xml</literal> file. The
configuration attributes in the <literal>TomcatClusteringCache</literal> MBean are very similar to
- those in the JBoss Enterprise Application Platform cache configuration.<xref linkend="jbosscache-cache"/>.</para>
+ those in the JBoss Enterprise Web Platform cache configuration.<xref linkend="jbosscache-cache"/>.</para>
<programlisting>
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
@@ -313,7 +313,7 @@
</mbean>
</programlisting>
- <para>Note that the value of the mbean element's code attribute is org.jboss.cache.aop.TreeCacheAop, which is different from the other JBoss Cache Mbeans used in JBoss Enterprise Application Platform. This is because FIELD granularity HTTP session replication (covered below) needs the added features of the <literal>TreeCacheAop</literal> (a.k.a. <literal>PojoCache</literal>) class.
+ <para>Note that the value of the mbean element's code attribute is org.jboss.cache.aop.TreeCacheAop, which is different from the other JBoss Cache Mbeans used in JBoss Enterprise Web Platform. This is because FIELD granularity HTTP session replication (covered below) needs the added features of the <literal>TreeCacheAop</literal> (a.k.a. <literal>PojoCache</literal>) class.
</para>
<para>The details of all the configuration options for a TreeCache MBean are covered in the JBoss Cache documentation. Below, we will just discuss several attributes that are most relevant to the HTTP cluster session replication.</para>
@@ -405,7 +405,7 @@
and needs to be replicated. This element has 3 valid values:</para>
<itemizedlist>
<listitem>
- <para><emphasis role="bold">SET_AND_GET</emphasis> is conservative but not optimal (performance-wise): it will always replicate session data even if its content has not been modified but simply accessed. This setting made (a little) sense in AS 4 since using it was a way to ensure that every request triggered replication of the session's timestamp. Since setting <literal>max_unreplicated_interval</literal> to 0 accomplishes the same thing at much lower cost, using <literal>SET_AND_GET</literal> makes no sense with Enterprise Application Platform 5.</para>
+ <para><emphasis role="bold">SET_AND_GET</emphasis> is conservative but not optimal (performance-wise): it will always replicate session data even if its content has not been modified but simply accessed. This setting made (a little) sense in AS 4 since using it was a way to ensure that every request triggered replication of the session's timestamp. Since setting <literal>max_unreplicated_interval</literal> to 0 accomplishes the same thing at much lower cost, using <literal>SET_AND_GET</literal> makes no sense with Enterprise Web Platform 5.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SET_AND_NON_PRIMITIVE_GET</emphasis> is conservative but will only replicate if an object of a non-primitive type has been accessed (i.e. the object is not of a well-known immutable JDK type such as <literal>Integer</literal>, <literal>Long</literal>, <literal>String</literal>, etc.) This is the default value.</para>
@@ -433,7 +433,7 @@
JBoss Cache configuration that should be used for storing distributable
sessions and replicating them around the cluster. This element lets web applications that require
different caching characteristics specify the use of separate, differently
- configured, JBoss Cache instances. In JBoss Enterprise Application Platform 4 the cache to use was a server-wide
+ configured, JBoss Cache instances. In JBoss Enterprise Web Platform 4 the cache to use was a server-wide
configuration that could not be changed per web application. The default value is <literal>standard-session-cache</literal>
if the <literal>replication-granularity</literal> is not <literal>FIELD</literal>,
<literal>field-granularity-session-cache</literal> if it is. See <xref linkend="clustering-http-state-cacheconfig"/>
@@ -520,7 +520,7 @@
<para>In previous releases, the default value if not explicitly set is the
<literal>LegacyClusteredSessionNotificationPolicy</literal>, which implements
- the behavior in previous JBoss versions. In JBoss Enterprise Application Platform 5, this was
+ the behavior in previous JBoss versions. In JBoss Enterprise Web Platform 5, this was
changed to <literal>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</literal>,
which implements the same behavior except during undeployment,
during which no <literal>HttpSessionListener</literal> and
@@ -534,7 +534,7 @@
relatively unused sessions from memory while storing them in persistent
storage. If a passivated session is requested by a client, it can be
"activated" back into memory and removed from the persistent store.
- JBoss Enterprise Application Platform 5 supports passivation of HttpSessions from web applications whose
+ JBoss Enterprise Web Platform 5 supports passivation of HttpSessions from web applications whose
<literal>web.xml</literal> includes the <literal>distributable</literal>
tag (i.e. clustered web applications).</para>
@@ -760,7 +760,7 @@
]]></programlisting>
<para>There is no need to annotate <literal>Student</literal>. POJO Cache will recognize it as @Replicable because it is a sub-class of <literal>Person</literal>.</para>
-<para>JBoss Enterprise Application Platform 5 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
+<para>JBoss Enterprise Web Platform 5 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -17,7 +17,7 @@
</para>
<para>
- The JBoss Enterprise Application Platform comes with clustering support out of
+ The JBoss Enterprise Web Platform comes with clustering support out of
the box, as part of the <literal>all</literal> configuration. The
<literal>all</literal> configuration includes support for the following:
@@ -81,22 +81,22 @@
<para>
In this <emphasis>Clustering Guide</emphasis> we aim to provide you with
- an in depth understanding of how to use JBoss Enterprise Application Platform's clustering features.
+ an in depth understanding of how to use JBoss Enterprise Web Platform's clustering features.
In this first part of the guide, the goal is to provide some basic "Quick Start"
- steps to encourage you to start experimenting with JBoss Enterprise Application Platform Clustering,
+ steps to encourage you to start experimenting with JBoss Enterprise Web Platform Clustering,
and then to provide some background information that will allow you to
- understand how JBoss Enterprise Application Platform Clustering works. The next part of the
+ understand how JBoss Enterprise Web Platform Clustering works. The next part of the
guide then explains in detail how to use these features to cluster
your JEE services. Finally, we provide some more details about advanced
configuration of JGroups and JBoss Cache, the core technologies that
- underlie JBoss Enterprise Application Platform Clustering.
+ underlie JBoss Enterprise Web Platform Clustering.
</para>
<section id="clustering-quickstart">
<title>Quick Start Guide</title>
<para>
The goal of this section is to give you the minimum information
- needed to let you get started experimenting with JBoss Enterprise Application Platform Clustering.
+ needed to let you get started experimenting with JBoss Enterprise Web Platform Clustering.
Most of the areas touched on in this section are covered in much greater
detail later in this guide.
</para>
@@ -104,19 +104,19 @@
<section id="clustering-quickstart-setup">
<title>Initial Preparation</title>
- <para>Preparing a set of servers to act as a JBoss Enterprise Application Platform cluster
+ <para>Preparing a set of servers to act as a JBoss Enterprise Web Platform cluster
involves a few simple steps:</para>
<itemizedlist>
<listitem id="clustering-prep-dualconfig">
- <para><emphasis role="bold">Install JBoss Enterprise Application Platform on all your servers.</emphasis>
+ <para><emphasis role="bold">Install JBoss Enterprise Web Platform on all your servers.</emphasis>
In its simplest form, this is just a matter of unzipping the JBoss
download onto the filesystem on each server. <!-- See the
<emphasis>Administration and Configuration Guide</emphasis> for
full details.--></para>
<para>If you want to run multiple
- JBoss Enterprise Application Platform instances on a single server, you can either install the
+ JBoss Enterprise Web Platform instances on a single server, you can either install the
full JBoss distribution onto multiple locations on your filesystem,
or you can simply make copies of the <literal>all</literal>
configuration. For example, assuming the root of the JBoss distribution
@@ -139,7 +139,7 @@
<listitem>
<para><emphasis role="bold">Ensure multicast is working.</emphasis>
- By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster
+ By default JBoss Enterprise Web Platform uses UDP multicast for most intra-cluster
communications. Make sure each server's networking configuration
supports multicast and that multicast support is enabled for any
switches or routers between your servers. If you are planning to
@@ -151,8 +151,8 @@
</para>
<note>
- <para>JBoss Enterprise Application Platform clustering does not require the use of UDP multicast;
- the Enterprise Application Platform can also be reconfigured to use TCP unicast for intra-cluster
+ <para>JBoss Enterprise Web Platform clustering does not require the use of UDP multicast;
+ the Enterprise Web Platform can also be reconfigured to use TCP unicast for intra-cluster
communication.</para>
</note>
</listitem>
@@ -172,13 +172,13 @@
<para>Beyond the above required steps, the following two optional steps are
recommended to help ensure that your cluster is properly isolated
- from other JBoss Enterprise Application Platform clusters that may be running on your network:</para>
+ from other JBoss Enterprise Web Platform clusters that may be running on your network:</para>
<itemizedlist>
<listitem>
<para id="clustering-prep-clustername">
<emphasis role="bold">Pick a unique name for your cluster.</emphasis>
- The default name for a JBoss Enterprise Application Platform cluster is "DefaultPartition". Come
+ The default name for a JBoss Enterprise Web Platform cluster is "DefaultPartition". Come
up with a different name for each cluster in your environment, e.g.
"QAPartition" or "BobsDevPartition". The use of "Partition" is not
required; it's just a semi-convention. As a small aid to performance
@@ -191,7 +191,7 @@
<listitem>
<para id="clustering-prep-mcastaddr">
<emphasis role="bold">Pick a unique multicast address for your cluster.</emphasis>
- By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster
+ By default JBoss Enterprise Web Platform uses UDP multicast for most intra-cluster
communication. Pick a different multicast address for each cluster
you run. Generally a good multicast address is of the form
<literal>239.255.x.y</literal>. See
@@ -209,7 +209,7 @@
</section>
<section id="clustering-quickstart-launching">
- <title>Launching a JBoss Enterprise Application Platform Cluster</title>
+ <title>Launching a JBoss Enterprise Web Platform Cluster</title>
<para>The simplest way to start a JBoss server cluster is to start
several JBoss instances on the same local network, using the
<literal>-c all</literal> command line option for each instance. Those
@@ -274,7 +274,7 @@
<literal>192.168.0.102</literal> addresses assigned, and that the two
JBoss instances use the same addresses and ServerPeerIDs as in
Scenario 1. The difference from Scenario 1 is we need to be sure
- each Enterprise Application Platform instance has its own work area. So, instead of using
+ each Enterprise Web Platform instance has its own work area. So, instead of using
the <literal>all</literal> config, we are going to use the
<literal>node1</literal> and <literal>node2</literal> configs we
copied from <literal>all</literal> earlier in <!--
@@ -344,12 +344,12 @@
</itemizedlist>
<para>That's it; that's all it takes to get a cluster of JBoss
- Enterprise Application Platform servers up and running.</para>
+ Enterprise Web Platform servers up and running.</para>
</section>
<section id="clustering-quickstart-http">
<title>Web Application Clustering Quick Start</title>
- <para>JBoss Enterprise Application Platform supports clustered web sessions, where a backup
+ <para>JBoss Enterprise Web Platform supports clustered web sessions, where a backup
copy of each user's <literal>HttpSession</literal> state is stored
on one or more nodes in the cluster. In case the primary node
handling the session fails or is shut down, any other node in the
@@ -362,9 +362,9 @@
<itemizedlist>
<listitem><para><emphasis role="bold">Configuring an External
Load Balancer</emphasis>. Web applications require an external
- load balancer to balance HTTP requests across the cluster of JBoss Enterprise Application Platform
+ load balancer to balance HTTP requests across the cluster of JBoss Enterprise Web Platform
instances (see <xref linkend="clustering-concepts-arch-balancer"/>
- for more on why that is). JBoss Enterprise Application Platform itself doesn't act as an HTTP load
+ for more on why that is). JBoss Enterprise Web Platform itself doesn't act as an HTTP load
balancer. So, you will need to set up a hardware or software
load balancer. There are many possible load balancer choices,
so how to configure one is really beyond the scope of a Quick Start.
@@ -388,7 +388,7 @@
</web-app></programlisting>
-<para>Simply doing that is enough to get the default JBoss Enterprise Application Platform
+<para>Simply doing that is enough to get the default JBoss Enterprise Web Platform
web session clustering behavior, which is appropriate for most
applications. See <xref linkend="clustering-http-state"/> for
more advanced configuration options.</para>
@@ -399,7 +399,7 @@
<section id="clustering-quickstart-ejbsessions">
<title>EJB Session Bean Clustering Quick Start</title>
- <para>JBoss Enterprise Application Platform supports clustered EJB session beans, whereby
+ <para>JBoss Enterprise Web Platform supports clustered EJB session beans, whereby
requests for a bean are balanced across the cluster. For
stateful beans a backup copy of bean state is maintained on one
or more cluster nodes, providing high availability in case the
@@ -442,7 +442,7 @@
<section id="clustering-quickstart-ejb3entities">
<title>Entity Clustering Quick Start</title>
- <para>One of the big improvements in the clustering area in JBoss Enterprise Application Platform 5
+ <para>One of the big improvements in the clustering area in JBoss Enterprise Web Platform 5
is the use of the new Hibernate/JBoss Cache integration for second level
entity caching that was introduced in Hibernate 3.3. In the JPA/Hibernate
context, a second level cache refers to a cache whose contents are
@@ -452,12 +452,12 @@
with second level caching enabled and disabled to see whether
it has a beneficial impact on your particular application.</para>
- <para>If you use more than one JBoss Enterprise Application Platform instance to run your
+ <para>If you use more than one JBoss Enterprise Web Platform instance to run your
JPA/Hibernate application and you use second level caching, you must
use a cluster-aware cache. Otherwise a cache on server A will still
hold out-of-date data after activity on server B updates some entities.</para>
- <para>JBoss Enterprise Application Platform provides a cluster-aware second level cache based on JBoss Cache.
- To tell JBoss Enterprise Application Platform's standard Hibernate-based JPA provider to enable
+ <para>JBoss Enterprise Web Platform provides a cluster-aware second level cache based on JBoss Cache.
+ To tell JBoss Enterprise Web Platform's standard Hibernate-based JPA provider to enable
second level caching with JBoss Cache, configure your
<literal>persistence.xml</literal> as follows:</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,13 +4,13 @@
<chapter id="jbosscache.chapt">
<title>JBoss Cache Configuration and Deployment</title>
<para>JBoss Cache provides the underlying distributed caching support used
- by many of the standard clustered services in a JBoss Enterprise Application Platform cluster. You can
+ by many of the standard clustered services in a JBoss Enterprise Web Platform cluster. You can
also deploy JBoss Cache in your own application to handle custom caching
requirements. In this chapter we provide some background on the main
configuration options available with JBoss Cache, with an emphasis on
how those options relate to the JBoss Cache usage by the standard clustered
- services the Enterprise Application Platform provides. We then discuss the different options available
- for deploying a custom cache in the Enterprise Application Platform.
+ services the Enterprise Web Platform provides. We then discuss the different options available
+ for deploying a custom cache in the Enterprise Web Platform.
</para>
<para>Users considering deploying JBoss Cache for direct use by their own
application are strongly encouraged to read the JBoss Cache
@@ -18,11 +18,11 @@
<ulink url="http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/">http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/</ulink>.</para>
<para>See also <xref linkend="clustering-blocks-jbc"/> for information on
- how the standard JBoss Enterprise Application Platform clustered services use JBoss Cache.</para>
+ how the standard JBoss Enterprise Web Platform clustered services use JBoss Cache.</para>
<section id="jbosscache-configuration">
<title>Key JBoss Cache Configuration Options</title>
- <para>JBoss Enterprise Application Platform ships with a reasonable set of default JBoss Cache
+ <para>JBoss Enterprise Web Platform ships with a reasonable set of default JBoss Cache
configurations that are suitable for the standard clustered service
use cases (e.g. web session replication or JPA/Hibernate caching).
Most applications that involve the standard
@@ -37,8 +37,8 @@
<para>Most JBoss Cache configuration examples in this section use the
JBoss Microcontainer schema for building up an <literal>org.jboss.cache.config.Configuration</literal>
object graph from XML. JBoss Cache has its own custom XML schema, but
- the standard JBoss Enterprise Application Platform CacheManager service uses the JBoss Microcontainer
- schema to be consistent with most other internal Enterprise Application Platform services.</para>
+ the standard JBoss Enterprise Web Platform CacheManager service uses the JBoss Microcontainer
+ schema to be consistent with most other internal Enterprise Web Platform services.</para>
<para>Before getting into the key configuration options, let's have a
look at the most likely place that a user would encounter them.</para>
@@ -46,7 +46,7 @@
<section id="jbosscache-configuration-cachemanager">
<title>Editing the CacheManager Configuration</title>
<para>As discussed in <xref linkend="clustering-blocks-jbc-cachemanager"/>,
- the standard JBoss Enterprise Application Platform clustered services use the CacheManager service
+ the standard JBoss Enterprise Web Platform clustered services use the CacheManager service
as a factory for JBoss Cache instances. So, cache configuration changes
are likely to involve edits to the CacheManager service.</para>
@@ -134,13 +134,13 @@
of child Java Beans for some of the more complex sub-configurations
(i.e. cache loading, eviction, buddy replication). Rather than
delegating this task of XML parsing/Java Bean creation to JBC, we
- let the Enterprise Application Platform's microcontainer do it directly. This has the advantage
+ let the Enterprise Web Platform's microcontainer do it directly. This has the advantage
of making the microcontainer aware of the configuration beans, which
- in later Enterprise Application Platform 5.x releases will be helpful in allowing external
+ in later Enterprise Web Platform 5.x releases will be helpful in allowing external
management tools to manage the JBC configurations.</para>
<para>The configuration format should be fairly self-explanatory if
- you look at the standard configurations the Enterprise Application Platform ships; they include
+ you look at the standard configurations the Enterprise Web Platform ships; they include
all the major elements. The types and properties of the various java
beans that make up a JBoss Cache configuration can be seen in the
JBoss Cache javadocs. Here is a fairly complete example:</para>
@@ -388,7 +388,7 @@
<para>Integration with a transaction manager is accomplished by
setting the <literal>transactionManagerLookupClass</literal> configuration
attribute; this specifies the fully qualified class name of a class JBoss Cache
- can use to find the local transaction manager. Inside JBoss Enterprise Application Platform, this
+ can use to find the local transaction manager. Inside JBoss Enterprise Web Platform, this
attribute would have one of two values:</para>
<itemizedlist>
@@ -405,7 +405,7 @@
that ships with JBoss Cache called the <literal>BatchModeTransactionManager</literal>.
This transaction manager is not a true JTA transaction manager and
should not be used for anything other than JBoss Cache. Its usage
- in JBoss Enterprise Application Platform is to get most of the benefits of JBoss Cache's transactional
+ in JBoss Enterprise Web Platform is to get most of the benefits of JBoss Cache's transactional
behavior for the session replication use cases, but without getting
tangled up with end user transactions that may run during a request.
</para>
@@ -461,10 +461,10 @@
reads.</para>
<para>Generally MVCC is a better choice than PESSIMISTIC, which is
deprecated as of JBoss Cache 3.0. But, for the session caching usage
- in JBoss Enterprise Application Platform 5.0.0, PESSIMISTIC is still the default. This is largely
+ in JBoss Enterprise Web Platform 5.0.0, PESSIMISTIC is still the default. This is largely
because for the session use case there are generally not concurrent
threads accessing the same cache location, so the benefits of MVCC
- are not as great. <!--, and 2) the Enterprise Application Platform development team wanted to continue
+ are not as great. <!--, and 2) the Enterprise Web Platform development team wanted to continue
to evaluate MVCC in the session use case before moving to it as the default.--></para>
</listitem>
<listitem>
@@ -503,8 +503,8 @@
<title>JGroups Integration</title>
<para>Each JBoss Cache instance internally uses a JGroups <literal>Channel</literal>
- to handle group communications. Inside JBoss Enterprise Application Platform, we strongly recommend
- that you use the Enterprise Application Platform's JGroups Channel Factory service <!--(see
+ to handle group communications. Inside JBoss Enterprise Web Platform, we strongly recommend
+ that you use the Enterprise Web Platform's JGroups Channel Factory service <!--(see
<xref linkend="clustering-blocks-jgroups-channelfactory"/>)--> as the
source for your cache's <literal>Channel</literal>. In this section
we discuss how to configure your cache to get it's channel from
@@ -578,7 +578,7 @@
<ulink url="http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf">http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf</ulink>.
For web session caches, eviction should not be configured; the
distributable session manager handles eviction itself. For EJB 3
- SFSB caches, stick with the eviction configuration in the Enterprise Application Platform's standard
+ SFSB caches, stick with the eviction configuration in the Enterprise Web Platform's standard
<literal>sfsb-cache</literal> configuration (see
<xref linkend="clustering-blocks-jbc-cachemanager"/>). The EJB container
will configure eviction itself using the values included in each bean's
@@ -620,7 +620,7 @@
Cache Loader passivaton.</para>
<para>In most cases you don't need to do anything to alter the cache
loader configurations for the standard web session and SFSB caches;
- the standard JBoss Enterprise Application Platform configurations should suit your needs. The
+ the standard JBoss Enterprise Web Platform configurations should suit your needs. The
following is a bit more detail in case you're interested or want to
change from the defaults.</para>
@@ -679,7 +679,7 @@
<listitem><para><emphasis role="bold">location</emphasis> property for
FileCacheLoaderConfig defines the root node of the filesystem tree where
passivated sessions should be stored. The default is to store them in
- your JBoss Enterprise Application Platform configuration's <literal>data</literal> directory.</para></listitem>
+ your JBoss Enterprise Web Platform configuration's <literal>data</literal> directory.</para></listitem>
<listitem><para><emphasis role="bold">async</emphasis> MUST be
<literal>false</literal> to ensure passivated sessions are promptly
written to the persistent store.</para></listitem>
@@ -801,7 +801,7 @@
<title>Deploying Your Own JBoss Cache Instance</title>
<para>It's quite common for users to deploy their own instances of
- JBoss Cache inside JBoss Enterprise Application Platform for custom use by their applications.
+ JBoss Cache inside JBoss Enterprise Web Platform for custom use by their applications.
In this section we describe the various ways caches can be
deployed.</para>
@@ -809,7 +809,7 @@
<title>Deployment Via the CacheManager Service</title>
<para>The standard JBoss clustered services that use JBoss Cache
- obtain a reference to their cache from the Enterprise Application Platform's CacheManager service
+ obtain a reference to their cache from the Enterprise Web Platform's CacheManager service
(see <xref linkend="clustering-blocks-jbc-cachemanager"/>). End
user applications can do the same thing; here's how.</para>
@@ -877,7 +877,7 @@
}]]></programlisting>
</listitem>
<listitem><para><emphasis role="bold">CacheManagerLocator</emphasis></para>
- <para>JBoss Enterprise Application Platform also provides a service locator object that can
+ <para>JBoss Enterprise Web Platform also provides a service locator object that can
be used to access the CacheManager.</para>
<programlisting><![CDATA[
@@ -890,7 +890,7 @@
public void start() throws Exception {
CacheManagerLocator locator = CacheManagerLocator.getCacheManagerLocator();
// Locator accepts as param a set of JNDI properties to help in lookup;
- // this isn't necessary inside the Enterprise Application Platform
+ // this isn't necessary inside the Enterprise Web Platform
cacheManager = locator.getCacheManager(null);
}
}]]></programlisting>
@@ -1012,7 +1012,7 @@
<title>Deployment Via a <literal>-jboss-beans.xml</literal> File</title>
<para>Much like it can deploy MBean services described with a
- <literal>-service.xml</literal>, JBoss Enterprise Application Platform 5 can also deploy services
+ <literal>-service.xml</literal>, JBoss Enterprise Web Platform 5 can also deploy services
that consist of Plain Old Java Objects (POJOs) if the POJOs are described
using the JBoss Microcontainer schema in a <literal>-jboss-beans.xml</literal>
file. You create such a file and deploy it, either directly in the
@@ -1084,7 +1084,7 @@
<literal>TransactionManager</literal> and a JGroups <literal>ChannelFactory</literal>
that are visible to the microcontainer are dependency injected into the
<literal>RuntimeConfig</literal>. The assumption here is that in some
- other deployment descriptor in the Enterprise Application Platform, the referenced beans have already
+ other deployment descriptor in the Enterprise Web Platform, the referenced beans have already
been described.</para>
<para>Using the configuration above, the "ExampleCache" cache will not
@@ -1127,7 +1127,7 @@
a JBoss Cache class that provides an MBean interface for a cache.
Adding an <annotation> element binds the JBoss Microcontainer
<literal>@JMX</literal> annotation to the bean; that in turn results
- in JBoss Enterprise Application Platform registering the bean in JXM as part of the deployment process.
+ in JBoss Enterprise Web Platform registering the bean in JXM as part of the deployment process.
</para>
<para>The actual underlying <literal>org.jboss.cache.Cache</literal> instance
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -7,10 +7,10 @@
<indexterm><primary>Clustering</primary><secondary>JBossCache and JGroups Services</secondary></indexterm>
JGroups and JBossCache provide the underlying communication, node replication and caching services, for
- JBoss Enterprise Application Platform clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans
+ JBoss Enterprise Web Platform clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans
for each type of clustering applications (e.g., the Stateful Session EJBs, HTTP session replication etc.).
</para>
- <para>The JBoss Enterprise Application Platform ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most
+ <para>The JBoss Enterprise Web Platform ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most
applications just work out of the box with the default MBean configurations. You only need to tweak them
when you are deploying an application that has special network or performance requirements.</para>
@@ -1054,7 +1054,7 @@
First, it's important to understand that the value set in any bind_addr element in an XML configuration file will be ignored by JGroups if it finds that system property jgroups.bind_addr (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) switch, the AS will set <literal>jgroups.bind_addr</literal> to the specified value.
</para>
<para>
- Beginning with Enterprise Application Platform 4.2.0, for security reasons the Enterprise Application Platform will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
+ Beginning with Enterprise Web Platform 4.2.0, for security reasons the Enterprise Web Platform will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
</para>
<para>
So, what are <emphasis>best practices</emphasis> for managing how JGroups binds to interfaces?
@@ -1105,7 +1105,7 @@
<section><title>Isolating JGroups Channels</title>
<para>
- Within JBoss Enterprise Application Platform, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
+ Within JBoss Enterprise Web Platform, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
</para>
<para>
It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss AS clustering.
@@ -1146,7 +1146,7 @@
<para>
The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
<screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all]]></screen>
-This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss Enterprise Application Platform:
+This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss Enterprise Web Platform:
</para>
<programlisting><![CDATA[<Config>
@@ -1154,7 +1154,7 @@
....]]>
</programlisting>
<para>
- Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss Enterprise Application Platform all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
+ Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss Enterprise Web Platform all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
</para>
<programlisting>
/run.sh -u 230.1.2.3 -g QAPartition -Djboss.hapartition.mcast_port=12345 -Djboss.webpartition.mcast_port=23456 -Djboss.ejb3entitypartition.mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 -c all
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,7 +4,7 @@
<chapter id="jgroups.chapt">
<title>JGroups Services</title>
<para>JGroups provides the underlying group communication support for
- JBoss Enterprise Application Platform clusters. The interaction of clustered
+ JBoss Enterprise Web Platform clusters. The interaction of clustered
services with JGroups was covered in <xref linkend="clustering-blocks-jgroups"/>.
This chapter focuses on the details of this interaction, with particular attention
to configuration details and troubleshooting tips.
@@ -21,7 +21,7 @@
<para>
The first section of this chapter covers the many JGroups
- configuration options in detail. JBoss Enterprise Application Platform
+ configuration options in detail. JBoss Enterprise Web Platform
ships with a set of default JGroups configurations. Most applications
will work with the default configurations out of the box. You will only
need to edit these configurations when you deploy an application with special
@@ -59,7 +59,7 @@
with the purpose of various protocols.
</para>
- <para>The JGroups configurations used in JBoss Enterprise Application Platform
+ <para>The JGroups configurations used in JBoss Enterprise Web Platform
appear as nested elements in the
<filename>$JBOSS_HOME/server/all/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename>
file. This file is parsed by the <literal>ChannelFactory</literal> service,
@@ -1281,7 +1281,7 @@
Within JBoss Application Server, there are a number of services that independently create JGroups channels — possibly multiple different JBoss Cache services (used for <literal>HttpSession</literal> replication, EJB3 stateful session bean replication and EJB3 entity replication), two JBoss Messaging channels, and <application>HAPartition</application>, the general purpose clustering service that underlies most other JBossHA services.
</para>
<para>
- It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss Enterprise Application Platform clustering.
+ It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss Enterprise Web Platform clustering.
</para>
<para>
Whom a JGroups channel will communicate with is defined by its group name and, for UDP-based channels, its multicast address and port. Isolating a JGroups channel means ensuring that different channels use different values for the group name, the multicast address and, in some cases, the multicast port.
@@ -1419,7 +1419,7 @@
<section id="jgroups-perf-udpbuffer">
<title>Improving UDP Performance by Configuring OS UDP Buffer Limits</title>
- <para>By default, the JGroups channels in JBoss Enterprise Application Platform use the UDP transport protocol to take advantage of IP multicast. However, one disadvantage
+ <para>By default, the JGroups channels in JBoss Enterprise Web Platform use the UDP transport protocol to take advantage of IP multicast. However, one disadvantage
of UDP is it does not come with the reliable delivery guarantees
provided by TCP. The protocols discussed in
<xref linkend="jgroups-reliable"/> allow JGroups to guarantee delivery of
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -11,9 +11,9 @@
<listitem>
<para>
Transparent failover of naming operations. If an HA-JNDI naming
- Context is connected to the HA-JNDI service on a particular JBoss Enterprise Application Platform
+ Context is connected to the HA-JNDI service on a particular JBoss Enterprise Web Platform
instance, and that service fails or is shut down, the HA-JNDI client
- can transparently fail over to another Enterprise Application Platform instance.
+ can transparently fail over to another Enterprise Web Platform instance.
</para>
</listitem>
<listitem>
@@ -219,13 +219,13 @@
<para>Configuring a client to use HA-JNDI is a matter of ensuring the
correct set of naming environment properties are available when a new
<literal>InitialContext</literal> is created. How this is done varies
- depending on whether the client is running inside JBoss Enterprise Application Platform itself or
+ depending on whether the client is running inside JBoss Enterprise Web Platform itself or
is in another VM.</para>
- <section><title>For clients running inside the Enterprise Application Platform</title>
+ <section><title>For clients running inside the Enterprise Web Platform</title>
<para>
- If you want to access HA-JNDI from inside the Enterprise Application Platform, you
+ If you want to access HA-JNDI from inside the Enterprise Web Platform, you
must explicitly configure your <literal>InitialContext</literal> by
passing in JNDI properties to the constructor. The following code shows
how to create a naming Context bound to HA-JNDI:
@@ -243,13 +243,13 @@
By default this service listens on the interface named via the
<literal>jboss.bind.address</literal> system property, which itself is set to
whatever value you assign to the <literal>-b</literal> command line option when
-you start JBoss Enterprise Application Platform (or <literal>localhost</literal> if not specified). The above
+you start JBoss Enterprise Web Platform (or <literal>localhost</literal> if not specified). The above
code shows an example of accessing this property.
</para>
<para>
However, this does not work in all cases, especially when running several
- JBoss Enterprise Application Platform instances on the same machine and bound to the same IP address, but
+ JBoss Enterprise Web Platform instances on the same machine and bound to the same IP address, but
configured to use different ports. A safer method is to not specify the
Context.PROVIDER_URL but instead allow the <literal>InitialContext</literal>
to statically find the in-VM HA-JNDI by specifying the <literal>jnp.partitionName</literal>
@@ -266,13 +266,13 @@
<para>This example uses the <literal>jboss.partition.name</literal> system
property to identify the partition with which the HA-JNDI service works. This
system property is set to whatever value you assign to the <literal>-g</literal>
-command line option when you start JBoss Enterprise Application Platform (or <literal>DefaultPartition</literal>
+command line option when you start JBoss Enterprise Web Platform (or <literal>DefaultPartition</literal>
if not specified).
</para>
<para>
Do not attempt to simplify things by placing a <literal>jndi.properties</literal>
- file in your deployment or by editing the Enterprise Application Platform's <literal>conf/jndi.properties</literal>
+ file in your deployment or by editing the Enterprise Web Platform's <literal>conf/jndi.properties</literal>
file. Doing either will almost certainly break things for your application
and quite possibly across the server. If you want to externalize
your client configuration, one approach is to deploy a properties file not
@@ -329,18 +329,18 @@
<para>The <literal>${jboss.bind.address}</literal> syntax used above tells JBoss
to use the value of the <literal>jboss.bind.address</literal> system property
when determining the URL. That system property is itself set to whatever value
- you assign to the <literal>-b</literal> command line option when you start JBoss Enterprise Application Platform.
+ you assign to the <literal>-b</literal> command line option when you start JBoss Enterprise Web Platform.
</para>
</section>
<section><title>Why do this programmatically and not just put this in a jndi.properties file?</title>
<para>
- The JBoss Enterprise Application Platform's internal naming environment is controlled by the <filename>conf/jndi.properties</filename> file, which should not be edited.
+ The JBoss Enterprise Web Platform's internal naming environment is controlled by the <filename>conf/jndi.properties</filename> file, which should not be edited.
</para>
<para>
- No other jndi.properties file should be deployed inside the Enterprise Application Platform because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.
+ No other jndi.properties file should be deployed inside the Enterprise Web Platform because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.
</para>
</section>
@@ -353,7 +353,7 @@
</section>
-<section><title>For clients running outside the Enterprise Application Platform</title>
+<section><title>For clients running outside the Enterprise Web Platform</title>
<para>The JNDI client needs to be aware of the HA-JNDI cluster. You can
pass a list of JNDI servers (i.e., the nodes in the HA-JNDI cluster) to the
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -5,12 +5,12 @@
<chapter id="Deployment">
<title>Deployment</title>
- <para>Deploying applications on JBoss Enterprise Application Platform is achieved by copy the application into the <filename>JBOSS_HOME/server/default/deploy</filename> directory. You can replace <emphasis>default</emphasis> with different server profiles such as <emphasis>all</emphasis> or <emphasis>minimal</emphasis>. We will cover those later in this chapter. The JBoss Enterprise Application Platform constantly scans the deploy directory to pick up new applications or any changes to existing applications. This enables the <emphasis>hot deployment</emphasis> of applications on the fly, while JBoss Enterprise Application Platform is still running.</para>
+ <para>Deploying applications on JBoss Enterprise Web Platform is achieved by copy the application into the <filename>JBOSS_HOME/server/default/deploy</filename> directory. You can replace <emphasis>default</emphasis> with different server profiles such as <emphasis>all</emphasis> or <emphasis>minimal</emphasis>. We will cover those later in this chapter. The JBoss Enterprise Web Platform constantly scans the deploy directory to pick up new applications or any changes to existing applications. This enables the <emphasis>hot deployment</emphasis> of applications on the fly, while JBoss Enterprise Web Platform is still running.</para>
<section id="Deployable_Application_Types">
<title>Deployable Application Types</title>
- <para>With JBoss Enterprise Application Platform 4.x, a deployer existed to handle a specified deployment type and that was the only deployer that would process the deployment. In JBoss Enterprise Application Platform 5, multiple deployers transform the metadata associated with a deployment until its processed by a deployer that creates a runtime component from the metadata. Deployment has to contain a descriptor that causes the component metadata to be added to the deployment. The types of deployments for which deployers exists by default in the JBoss Enterprise Application Platform include:</para>
+ <para>With JBoss Enterprise Web Platform 4.x, a deployer existed to handle a specified deployment type and that was the only deployer that would process the deployment. In JBoss Enterprise Web Platform 5, multiple deployers transform the metadata associated with a deployment until its processed by a deployer that creates a runtime component from the metadata. Deployment has to contain a descriptor that causes the component metadata to be added to the deployment. The types of deployments for which deployers exists by default in the JBoss Enterprise Web Platform include:</para>
<itemizedlist>
<listitem>
@@ -25,16 +25,16 @@
<listitem>
<indexterm><primary>JBoss Microcontainer</primary><secondary>beans deployment type</secondary></indexterm>
- <para>The JBoss Microcontainer (MC) beans archive (typical suffixes include, .beans, .deployer) packages a POJO deployment in a JAR file with a <filename>META-INF/jboss-beans.xml</filename> descriptor. This format is commonly used by the JBoss Enterprise Application Platform component deployers.</para></listitem>
+ <para>The JBoss Microcontainer (MC) beans archive (typical suffixes include, .beans, .deployer) packages a POJO deployment in a JAR file with a <filename>META-INF/jboss-beans.xml</filename> descriptor. This format is commonly used by the JBoss Enterprise Web Platform component deployers.</para></listitem>
<listitem>
<indexterm><primary>SAR</primary><see>Service Archive</see></indexterm>
<indexterm><primary>Service Archive</primary><secondary>deployment type</secondary></indexterm>
- <para>The SAR application archive (e.g., myservice.sar) packages a JBoss service in a JAR file. It is mostly used by JBoss Enterprise Application Platform internal services that have not been updated to support MC beans style deployments.</para></listitem>
+ <para>The SAR application archive (e.g., myservice.sar) packages a JBoss service in a JAR file. It is mostly used by JBoss Enterprise Web Platform internal services that have not been updated to support MC beans style deployments.</para></listitem>
<listitem>
<indexterm><primary>DataSource</primary><secondary>deployment type</secondary></indexterm>
- <para>The <filename>*-ds.xml</filename> file defines connections to external databases. The data source can then be reused by all applications and services in JBoss Enterprise Application Platform via the internal JNDI.</para></listitem>
+ <para>The <filename>*-ds.xml</filename> file defines connections to external databases. The data source can then be reused by all applications and services in JBoss Enterprise Web Platform via the internal JNDI.</para></listitem>
<listitem>
<indexterm><primary>JBoss Microcontainer</primary><secondary>*-jboss-beans.xml deployment type</secondary></indexterm>
@@ -43,16 +43,16 @@
<listitem>
<indexterm><primary>Service Archive</primary><secondary>*-service.xml deployment type</secondary></indexterm>
- <para>You can deploy <filename>*-service.xml</filename> files with MBean service definitions. If you have the appropriate JAR files available in the deploy or lib directories, the MBeans specified in the XML files will be started. This is the way you deploy many JBoss Enterprise Application Platform internal services that have not been updated to support POJO style deployment, such as the JMS queues.</para></listitem>
+ <para>You can deploy <filename>*-service.xml</filename> files with MBean service definitions. If you have the appropriate JAR files available in the deploy or lib directories, the MBeans specified in the XML files will be started. This is the way you deploy many JBoss Enterprise Web Platform internal services that have not been updated to support POJO style deployment, such as the JMS queues.</para></listitem>
-<listitem><para>You can also deploy JAR files containing EJBs or other service objects directly in JBoss Enterprise Application Platform. The list of suffixes that are recognized as JAR files is specified in the <filename>conf/bootstrap/deployers.xml</filename> JARStructure bean constructor set.</para></listitem>
+<listitem><para>You can also deploy JAR files containing EJBs or other service objects directly in JBoss Enterprise Web Platform. The list of suffixes that are recognized as JAR files is specified in the <filename>conf/bootstrap/deployers.xml</filename> JARStructure bean constructor set.</para></listitem>
</itemizedlist>
<note>
<title>Exploded Deployment</title>
<indexterm><primary>Exploded Deployment</primary></indexterm>
- <para>The WAR, EAR, MC beans and SAR deployment packages are really just JAR files with special XML deployment descriptors in directories like META-INF and WEB-INF. JBoss Enterprise Application Platform allows you to deploy those archives as expanded directories instead of JAR files. That allows you to make changes to web pages etc on the fly without re-deploying the entire application. If you do need to re-deploy the exploded directory without re-start the server, you can just <code>touch</code> the deployment descriptors (e.g., the <filename>WEB-INF/web.xml</filename> in a WAR and the <filename>META-INF/application.xml</filename> in an EAR) to update their timestamps.</para>
+ <para>The WAR, EAR, MC beans and SAR deployment packages are really just JAR files with special XML deployment descriptors in directories like META-INF and WEB-INF. JBoss Enterprise Web Platform allows you to deploy those archives as expanded directories instead of JAR files. That allows you to make changes to web pages etc on the fly without re-deploying the entire application. If you do need to re-deploy the exploded directory without re-start the server, you can just <code>touch</code> the deployment descriptors (e.g., the <filename>WEB-INF/web.xml</filename> in a WAR and the <filename>META-INF/application.xml</filename> in an EAR) to update their timestamps.</para>
</note>
</section>
@@ -62,13 +62,13 @@
<indexterm><primary>Server Configuration</primary><see>Server Profile</see></indexterm>
<indexterm><primary>Server Profile</primary><secondary>definition</secondary></indexterm>
- <para>The JBoss Enterprise Application Platform ships with six server profiles. You can choose which configuration to start by passing the <code>-c</code> parameter to the server startup script. For instance, the <code>run.sh -c all</code> command would start the server in the <emphasis>all</emphasis> profile. Each profile is contained in a directory named <filename>JBOSS_HOME/server/[profile name]/</filename>. You can look into each server profile's directory to see the services, applications, and libraries included in the profile.</para>
+ <para>The JBoss Enterprise Web Platform ships with six server profiles. You can choose which configuration to start by passing the <code>-c</code> parameter to the server startup script. For instance, the <code>run.sh -c all</code> command would start the server in the <emphasis>all</emphasis> profile. Each profile is contained in a directory named <filename>JBOSS_HOME/server/[profile name]/</filename>. You can look into each server profile's directory to see the services, applications, and libraries included in the profile.</para>
<note><para>The exact contents of the <filename>server/[profile name]</filename> directory depends on the profile service implementation and is subject to change as the management layer and embedded server evolve.</para></note>
<itemizedlist>
<listitem>
<indexterm><primary>Profiles</primary><secondary>minimal</secondary></indexterm>
- <para>The minimal profile starts the core server container without any of the enterprise services. It is a good starting point if you want to build a customized version of JBoss Enterprise Application Platform that only contains the services you need.</para></listitem>
+ <para>The minimal profile starts the core server container without any of the enterprise services. It is a good starting point if you want to build a customized version of JBoss Enterprise Web Platform that only contains the services you need.</para></listitem>
<listitem>
<indexterm><primary>Profiles</primary><secondary>default</secondary></indexterm>
<para>The <emphasis>default</emphasis> profile is the mostly common used profile for application developers. It supports the standard Java EE 5.0 programming APIs (e.g., Annotations, JPA, and EJB3).</para></listitem>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -10,11 +10,11 @@
<indexterm><primary>EJB3</primary><see>Enterprise Applications with EJB3 Services</see></indexterm>
EJB3 (Enterprise Java Bean 3.0) provides the core component model for Java EE 5 applications. An EJB3 bean is a managed component that is automatically wired to take advantage of all services the Java EE 5 server container provides, such as transaction, security, persistence, naming, dependency injection, etc. The managed component allows developers to focus on the business logic, and leave the cross-cutting concerns to the container as configurations. As an application developer, you need not create or destroy the components yourself. You only need to ask for an EJB3 bean from the Java EE container by its name, and then you can call its methods with all configured container services applied. You can get access to an EJB3 bean from either inside or outside of the Java EE container. </para>
-<para>JBoss Enterprise Application Platform 5 supports EJB3 out of the box. Note that JBoss Enterprise Application Platform 4.2 is a J2EE server, so it does not support the full EJB3 feature set. </para>
+<para>JBoss Enterprise Web Platform 5 supports EJB3 out of the box. Note that JBoss Enterprise Web Platform 4.2 is a J2EE server, so it does not support the full EJB3 feature set. </para>
<para>The details of the EJB3 component programming model is beyond the scope of this guide. Most EJB3 interfaces and annotations are part of the Java EE 5 standard and hence they are the same for all Java EE 5 compliant application servers. Interested readers should refer to the EJB3 specification or numerous EJB3 books to learn more about EJB3 programming.</para>
- <para>In this chapter, we only cover EJB3 configuration issues that are specific to the JBoss Enterprise Application Platform. For instance, we discuss the JNDI naming conventions for EJB3 components inside the JBoss Enterprise Application Platform, the optional configurations for the Hibernate persistence engine for entity beans, as well as custom options in the JBoss EJB3 deployer.</para>
+ <para>In this chapter, we only cover EJB3 configuration issues that are specific to the JBoss Enterprise Web Platform. For instance, we discuss the JNDI naming conventions for EJB3 components inside the JBoss Enterprise Web Platform, the optional configurations for the Hibernate persistence engine for entity beans, as well as custom options in the JBoss EJB3 deployer.</para>
<section id="EJB3_Services-Session_Beans">
<title>Session Beans</title>
@@ -87,7 +87,7 @@
<note>
<title>Injecting EJB3 Beans into the Web Tier</title>
- <para>Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss Enterprise Application Platform 4.2. However, the JBoss Enterprise Platform provides an integration framework called JBoss Seam. JBoss Seam brings EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. Please see more details in the JBoss Seam reference guide bundled with the platform.</para>
+ <para>Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss Enterprise Web Platform 4.2. However, the JBoss Enterprise Platform provides an integration framework called JBoss Seam. JBoss Seam brings EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. Please see more details in the JBoss Seam reference guide bundled with the platform.</para>
</note>
</section>
@@ -214,7 +214,7 @@
<para>The EntityManager API is great, but how does the server know which database it is supposed to save / update / query the entity objects? How do we configure the underlying object-relational-mapping engine and cache for better performance and trouble shooting? The persistence.xml file gives you complete flexibility to configure the EntityManager.</para>
- <para>The persistence.xml file is a standard configuration file in JPA. It has to be included in the META-INF directory inside the JAR file that contains the entity beans. The persistence.xml file must define a persistence-unit with a unique name in the current scoped classloader. The provider attribute specifies the underlying implementation of the JPA EntityManager. In JBoss Enterprise Application Platform, the default and only supported / recommended JPA provider is Hibernate. The jta-data-source points to the JNDI name of the database this persistence unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the JBoss Enterprise Application Platform. Please refer to <xref linkend="alternative_DBs"/> on how to setup alternative databases for JBoss AS.</para>
+ <para>The persistence.xml file is a standard configuration file in JPA. It has to be included in the META-INF directory inside the JAR file that contains the entity beans. The persistence.xml file must define a persistence-unit with a unique name in the current scoped classloader. The provider attribute specifies the underlying implementation of the JPA EntityManager. In JBoss Enterprise Web Platform, the default and only supported / recommended JPA provider is Hibernate. The jta-data-source points to the JNDI name of the database this persistence unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the JBoss Enterprise Web Platform. Please refer to <xref linkend="alternative_DBs"/> on how to setup alternative databases for JBoss AS.</para>
<programlisting>
<![CDATA[
@@ -236,7 +236,7 @@
<para>However, if you deploy your EAR application in its own scoped classloader and have only one persistence-unit defined in the whole application, you can omit the "name" on @PersistenceContext. See later in this chapter for EAR packaging and deployment.</para>
</note>
- <para>The properties element in the persistence.xml can contain any configuration properties for the underlying persistence provider. Since JBoss Enterprise Application Platform uses Hibernate as the EJB3 persistence provider, you can pass in any Hibernate options here. Please refer to the Hibernate and Hibernate EntityManager documentation for more details. Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops.</para>
+ <para>The properties element in the persistence.xml can contain any configuration properties for the underlying persistence provider. Since JBoss Enterprise Web Platform uses Hibernate as the EJB3 persistence provider, you can pass in any Hibernate options here. Please refer to the Hibernate and Hibernate EntityManager documentation for more details. Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops.</para>
<programlisting>
<![CDATA[
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -14,7 +14,7 @@
</para>
</listitem>
<listitem>
- <para>You have <track-connection-by-tx/> in your oracle-xa-ds.xml (not necessarily for JBoss Enterprise Application Platform 5.x where it is enabled by default and the element is deprecated).
+ <para>You have <track-connection-by-tx/> in your oracle-xa-ds.xml (not necessarily for JBoss Enterprise Web Platform 5.x where it is enabled by default and the element is deprecated).
</para>
</listitem>
<listitem>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -5,7 +5,7 @@
<title>General Configuration</title>
<para>
<indexterm><primary>Configuration</primary><secondary>general</secondary></indexterm>
-This chapter covers general configuration issues for the JBoss Enterprise Application Platform.
+This chapter covers general configuration issues for the JBoss Enterprise Web Platform.
</para>
<!--
@@ -15,12 +15,12 @@
</para>
</section>-->
-<section><title>Hosting multiple domains with your JBoss Enterprise Application Platform</title>
+<section><title>Hosting multiple domains with your JBoss Enterprise Web Platform</title>
<para>
This section discusses how you can use your application server to host multiple applications for multiple domains.
</para>
<para>
- In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss Enterprise Application Platform server:
+ In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss Enterprise Web Platform server:
<orderedlist>
<listitem>
<para>www.domainA11.net</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -5,11 +5,11 @@
<chapter id="JBoss_Enterprise_Application_Platform_5_Introduction">
<title>Introduction</title>
<para>
- <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>microcontainer</secondary></indexterm>
- JBoss Enterprise Application Platform 5 is built on top of the new JBoss Microcontainer.
+ <indexterm><primary>JBoss Enterprise Web Platform</primary><secondary>microcontainer</secondary></indexterm>
+ JBoss Enterprise Web Platform 5 is built on top of the new JBoss Microcontainer.
The JBoss Microcontainer is a lightweight container that supports direct deployment, configuration and lifecycle of plain old Java objects (POJOs).
- <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>JMX Microkernel</secondary></indexterm>
- The JBoss Microcontainer project is standalone and replaces the JBoss JMX Microkernel used in the 4.x JBoss Enterprise Application Platforms.
+ <indexterm><primary>JBoss Enterprise Web Platform</primary><secondary>JMX Microkernel</secondary></indexterm>
+ The JBoss Microcontainer project is standalone and replaces the JBoss JMX Microkernel used in the 4.x JBoss Enterprise Web Platforms.
<!-- Project goals include: -->
</para>
<!-- <para>
@@ -42,17 +42,17 @@
</itemizedlist> -->
<para>
The JBoss Microcontainer integrates nicely with the JBoss Aspect
- Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBoss Enterprise Application Platform 5 remains strong and MBean services written against the old Microkernel are expected to work.
+ Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBoss Enterprise Web Platform 5 remains strong and MBean services written against the old Microkernel are expected to work.
</para>
<!--<para>
- JBoss Enterprise Application Platform 5 is designed around the advanced concept of a Virtual Deployment
+ JBoss Enterprise Web Platform 5 is designed around the advanced concept of a Virtual Deployment
Framework (VDF).
- The JBoss Enterprise Application Platform 5 Virtual Deployment Framework (VDF) takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. It is also based on the POJO microntainer rather than JMX as in previous releases. More information about the Virtual Deployment Framework (VDF) can be found in <xref linkend="virtual_deployment_framework"/>.
+ The JBoss Enterprise Web Platform 5 Virtual Deployment Framework (VDF) takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. It is also based on the POJO microntainer rather than JMX as in previous releases. More information about the Virtual Deployment Framework (VDF) can be found in <xref linkend="virtual_deployment_framework"/>.
</para>-->
<para>
- A sample Java EE 5 application that can be run on top of JBoss Enterprise Application Platform 5.0.0.GA and above which demonstrates many interesting technologies is the Seam Booking Application available with this distribution. This example application makes use of the following technologies running on JBoss Enterprise Application Platform 5:</para>
+ A sample Java EE 5 application that can be run on top of JBoss Enterprise Web Platform 5.0.0.GA and above which demonstrates many interesting technologies is the Seam Booking Application available with this distribution. This example application makes use of the following technologies running on JBoss Enterprise Web Platform 5:</para>
<itemizedlist>
<listitem>
@@ -97,16 +97,16 @@
</itemizedlist>
<para>
- Many key features of JBoss Enterprise Application Platform 5 are provided by integrating standalone JBoss projects which include:</para>
+ Many key features of JBoss Enterprise Web Platform 5 are provided by integrating standalone JBoss projects which include:</para>
<itemizedlist>
<listitem>
<para>
- JBoss EJB3 included with JBoss Enterprise Application Platform 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
+ JBoss EJB3 included with JBoss Enterprise Web Platform 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
</para>
</listitem>
<listitem>
<para>
- JBoss Messaging is a high performance JMS provider included in JBoss Enterprise Application Platform 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for JBoss Enterprise Application Platform 4.2.
+ JBoss Messaging is a high performance JMS provider included in JBoss Enterprise Web Platform 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for JBoss Enterprise Web Platform 4.2.
</para>
</listitem>
<listitem>
@@ -116,26 +116,26 @@
</listitem>
<listitem>
<para>
- JBossWS 3.x is the web services stack for JBoss Enterprise Application Platform 5 providing Java EE compatible web services, JAXWS-2.x.
+ JBossWS 3.x is the web services stack for JBoss Enterprise Web Platform 5 providing Java EE compatible web services, JAXWS-2.x.
</para>
</listitem>
<listitem>
<para>
- JBoss Transactions is the default transaction manager for JBoss Enterprise Application Platform 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
+ JBoss Transactions is the default transaction manager for JBoss Enterprise Web Platform 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
</para>
</listitem>
<listitem>
<para>
- JBoss Web is the Web container in JBoss Enterprise Application Platform 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
+ JBoss Web is the Web container in JBoss Enterprise Web Platform 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
</para>
</listitem>
</itemizedlist>
<!--<para>
-JBoss Enterprise Application Platform 5 includes numerous features and bug fixes, many of them carried over from the JBoss Enterprise Application Platform 4.x codebase. See the Detailed Release Notes section for the full details.
+JBoss Enterprise Web Platform 5 includes numerous features and bug fixes, many of them carried over from the JBoss Enterprise Web Platform 4.x codebase. See the Detailed Release Notes section for the full details.
</para>-->
<section id="JBossAS_Use_Cases">
- <title>JBoss Enterprise Application Platform Use Cases</title>
+ <title>JBoss Enterprise Web Platform Use Cases</title>
<itemizedlist>
<listitem>
<para>
@@ -149,7 +149,7 @@
</listitem>
<listitem>
<para>
- Simple web applications with JSPs/Servlets upgrades to JBoss Enterprise Application Platform with Tomcat Embedded.
+ Simple web applications with JSPs/Servlets upgrades to JBoss Enterprise Web Platform with Tomcat Embedded.
</para>
</listitem>
<listitem>
@@ -172,7 +172,7 @@
<!-- <section id="Community_EAP_Diffs">
<title>JBossAS Community Version vs EAP</title>
- <subtitle>What is the difference between the community JBoss Application Server and the JBoss Enterprise Application Platform?</subtitle>
+ <subtitle>What is the difference between the community JBoss Application Server and the JBoss Enterprise Web Platform?</subtitle>
<para>
<indexterm><primary>JBossAS</primary><secondary>community vs EAP versions</secondary></indexterm>
The community JBoss Application Server is sponsored by JBoss/Red Hat. It allows innovation at a faster pace.
@@ -182,9 +182,9 @@
Fueled by the thriving JBoss.org community, JBoss Enterprise Middleware is a comprehensive middleware portfolio that combines and integrates the latest enterprise-ready features from JBoss.org into stable, enterprise-class platform distributions. JBoss Enterprise Middleware further mitigates risk with industry leading 24x7 support and multi-year update and maintenance policies. This means you have an enterprise-class open source option for application and service hosting, content aggregation, data federation, and service integration – for both development and production.
</para>
<para>
- <indexterm><primary>EAP</primary><see>Enterprise Application Platform</see></indexterm>
- <indexterm><primary>Enterprise Application Platform</primary><secondary>definition</secondary></indexterm>
- JBoss Enterprise Application Platform is a rigorously tested, stable, supported platform for developing and deploying mission critical Java applications and services. It integrates code from the JBoss.org Application Server/Clustering project, <ulink url="www.seamframework.org">JBoss Hibernate Framework</ulink>, <ulink url="www.seamframework.org">JBoss Seam Framework</ulink> into a single distribution with a single patch and update stream, multi-year maintenance policy. JBoss EAP is certified on 17 operating systems, 5 Database Management systems and JVM combinations. It also integrates with <ulink url="http://www.jboss.com/products/devstudio">JBoss Developer Studio</ulink> and the <ulink url="https://support.redhat.com/jbossnetwork">JBoss Operations Network</ulink>.
+ <indexterm><primary>EAP</primary><see>Enterprise Web Platform</see></indexterm>
+ <indexterm><primary>Enterprise Web Platform</primary><secondary>definition</secondary></indexterm>
+ JBoss Enterprise Web Platform is a rigorously tested, stable, supported platform for developing and deploying mission critical Java applications and services. It integrates code from the JBoss.org Application Server/Clustering project, <ulink url="www.seamframework.org">JBoss Hibernate Framework</ulink>, <ulink url="www.seamframework.org">JBoss Seam Framework</ulink> into a single distribution with a single patch and update stream, multi-year maintenance policy. JBoss EAP is certified on 17 operating systems, 5 Database Management systems and JVM combinations. It also integrates with <ulink url="http://www.jboss.com/products/devstudio">JBoss Developer Studio</ulink> and the <ulink url="https://support.redhat.com/jbossnetwork">JBoss Operations Network</ulink>.
</para>
<para>
Key benefits of using JBoss:
@@ -234,7 +234,7 @@
<para>
- More information about JBoss Enterprise Application Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>
+ More information about JBoss Enterprise Web Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>
</para>
</section>
@@ -242,7 +242,7 @@
<section id="JBoss_Enterprise_Application_Platform_5_Compatibility_Issues">
<title>JBoss Application Server 5 Compatibility Issues</title>
<para>
- The following are current compatibility issues for JBoss Enterprise Application Platform 5:
+ The following are current compatibility issues for JBoss Enterprise Web Platform 5:
</para>
<section id="Java6_Notes">
<title>Java 6 Notes</title>
@@ -289,9 +289,9 @@
<section>
<title>Other JBossAS </title>
<para>The ClassPathExtension MBean has been replaced with a VFS classloader definition, see JBAS-5446.</para>
- <para>The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see <ulink url="http://www.jboss.org/community/docs/DOC-9038">Enterprise Application Platform 5ServiceBindingManager Wiki</ulink>.</para>
+ <para>The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see <ulink url="http://www.jboss.org/community/docs/DOC-9038">Enterprise Web Platform 5ServiceBindingManager Wiki</ulink>.</para>
<para>The Farm service from 4.x has been removed, and replaced with a HASingletonDeploymentScanner that integrates with the ProfileService.</para>
- <para>JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that run in AS 4.2 may fail in Enterprise Application Platform 5. We have tried to keep the validation messages as accurate as possible in order to help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.</para>
+ <para>JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that run in AS 4.2 may fail in Enterprise Web Platform 5. We have tried to keep the validation messages as accurate as possible in order to help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.</para>
<para>A new jboss.server.log.threshold system property can be used to control the log/server.log threshold. It defaults to DEBUG.</para>
<para>The default conf/jboss-log4j.xml configuration now includes the thread name for entries in log/server.log (JBAS-5274).</para>
<para>The transaction manager configuration has moved from conf/jboss-service.xml to deploy/transaction-service.xml.</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -6,7 +6,7 @@
<para>
<indexterm><primary>JGroups</primary><secondary>multicast communication toolkit</secondary></indexterm>
- JBoss Enterprise Application Platform clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
+ JBoss Enterprise Web Platform clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Web Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
</para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -6,7 +6,7 @@
<title>Microcontainer</title>
<!--<indexterm><primary>MC</primary><see>JBoss Microcontainer</see></indexterm>-->
- <para>JBoss Enterprise Application Platform 5.0 uses the Microcontainer to integrate enterprise services
+ <para>JBoss Enterprise Web Platform 5.0 uses the Microcontainer to integrate enterprise services
together with a Servlet/JSP container, EJB container, deployers and management utilities in order to
provide a standard Java EE environment. If you need additional services then you can simply deploy
these on top of Java EE to provide the functionality you need. Likewise any services that you do not
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -2,16 +2,16 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
]>
<chapter id="performance_tuning">
- <title>JBoss Enterprise Application Platform 5 Performance Tuning</title>
+ <title>JBoss Enterprise Web Platform 5 Performance Tuning</title>
<section id="Tuning_Introduction">
<title>Introduction</title>
<para>
- <indexterm><primary>JBoss Enterprise Application Platform 5 Performance Tuning</primary><secondary>performance</secondary></indexterm>
- <indexterm><primary>Performance</primary><secondary>JBoss Enterprise Application Platform 5 Performance Tuning</secondary></indexterm>
- <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>performance tuning</secondary></indexterm>
- Developing applications and deploying them to an Enterprise Application Platform does not guarantee best performance without performance tuning of the applications and server.
- Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and Enterprise Application Platform.
+ <indexterm><primary>JBoss Enterprise Web Platform 5 Performance Tuning</primary><secondary>performance</secondary></indexterm>
+ <indexterm><primary>Performance</primary><secondary>JBoss Enterprise Web Platform 5 Performance Tuning</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Web Platform</primary><secondary>performance tuning</secondary></indexterm>
+ Developing applications and deploying them to an Enterprise Web Platform does not guarantee best performance without performance tuning of the applications and server.
+ Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and Enterprise Web Platform.
</para>
<para>
Application design, hardware/network profile, operating system, application software development, testing and deployment all play a major role in performance tuning. A bottleneck in performance therefore could be caused by these factors not just your application. Recent studies show that most performance problems are the result of the applications not the middleware or the operating systems. This could be associated with the technological developments in computer software, hardware and networking which has increased their reliability.
@@ -25,7 +25,7 @@
<section id="Hardware_Tuning">
<title>Hardware tuning</title>
<para>
- To develop a suitable hardware configuration that suits the performance of your applications on the JBoss Enterprise Application Platform, you need to understand the impact that the selected hardware configuration may have on other applications and overall operating system performance.
+ To develop a suitable hardware configuration that suits the performance of your applications on the JBoss Enterprise Web Platform, you need to understand the impact that the selected hardware configuration may have on other applications and overall operating system performance.
</para>
<para>
To understand hardware performance tuning issues, it is also very critical to understand the hardware architecture of your system.
@@ -150,7 +150,7 @@
In addition, using benchmarking tools to test your applications may be a quick way to pinpoint issues in your code which can often be causes for performance bottlenecks. Iterative tests are recommended to identify cache and other hardware issues that may arise due to start up or other factors.
</para>
<para>
- The JBoss Enterprise Application Platform web console <ulink url="http://localhost:8080/web-console/">http://localhost:8080/web-console/</ulink> provides you with monitoring tools starting with the JVM environment statistics on the default page and access to monitoring tools and snapshots.
+ The JBoss Enterprise Web Platform web console <ulink url="http://localhost:8080/web-console/">http://localhost:8080/web-console/</ulink> provides you with monitoring tools starting with the JVM environment statistics on the default page and access to monitoring tools and snapshots.
</para>
<note><title>Performance Monitor v/s Profiler</title>
@@ -172,7 +172,7 @@
Instrumentation in the past would have had to be embedded in the application. Today, there are many solutions for instrumentation that do not require developers to code. Commercial products, and the JBoss AOP framework can be used for just this purpose. You can also turn on call statistics in the containers, and Hibernate statistics. For more on this please refer to the AOP and Hibernate project pages.
</para>
<para>
- Taking successive thread dumps (includes the current call stack for each Java Enterprise Application Platform thread) can give the application developers enough information to get a sense for what is going on in the application. This is something that you might do after the application has hit a performance wall. If the performance problem lasts for five minutes, you might generate a thread dump one a minute. You can use the JVM "jps -l" command to get a list of running Java applications and the process ids for each. Note the process ID for the "org.jboss.Main" application. You will then run the "jstack ProcessID" command (replacing ProcessID with the "org.jboss.Main" process ID) and that will generate the thread dump. Of course, you should redirect the output of the jstack command to save the output ("jstack ProcessID > threaddump1.txt").
+ Taking successive thread dumps (includes the current call stack for each Java Enterprise Web Platform thread) can give the application developers enough information to get a sense for what is going on in the application. This is something that you might do after the application has hit a performance wall. If the performance problem lasts for five minutes, you might generate a thread dump one a minute. You can use the JVM "jps -l" command to get a list of running Java applications and the process ids for each. Note the process ID for the "org.jboss.Main" application. You will then run the "jstack ProcessID" command (replacing ProcessID with the "org.jboss.Main" process ID) and that will generate the thread dump. Of course, you should redirect the output of the jstack command to save the output ("jstack ProcessID > threaddump1.txt").
</para>
@@ -181,14 +181,14 @@
<section id="JBAS_Tuning">
- <title>Tuning JBoss Enterprise Application Platform</title>
+ <title>Tuning JBoss Enterprise Web Platform</title>
<para>
- Before tuning the JBoss Enterprise Application Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the server. This section discusses these among other JBoss Enterprise Application Platform performance tuning topics.
+ Before tuning the JBoss Enterprise Web Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the server. This section discusses these among other JBoss Enterprise Web Platform performance tuning topics.
</para>
<section id="Memory_Usage_Tuning"><title>Memory usage</title>
<para>
- Memory usage of Java applications including the JBoss Enterprise Application Platform is dictated by the heap space allocated. You could therefore as an example, reduce 1GB heap space you currently have allocated to 800MB to reduce memory footprint (if you have enough headroom).
+ Memory usage of Java applications including the JBoss Enterprise Web Platform is dictated by the heap space allocated. You could therefore as an example, reduce 1GB heap space you currently have allocated to 800MB to reduce memory footprint (if you have enough headroom).
</para>
<para>
The Java Virtual Machine (JVM) manages segments (generations) of memory. If a segment of the heap space is exhausted, you will see a Java OutOfMemoryError (OOME). All bets are off, when you get a Java OutOfMemoryError. The application should be restarted to correct any bad state. Part of tuning is checking how much memory headroom you have while under load. If available memory is too low, you will need to increase the max Java memory size (possibly switching to a 64-bit JVM if needed).
@@ -226,7 +226,7 @@
<property>jboss.vfs.forceCopy</property> - has the options true and false, with the default being false.
</para>
<para>
- This defines how nested jars should be handled. If forceCopy equals true, we create a temporary copy of the nested jar, and re-wire VFS accordingly. If forceCopy equals false, we handle nested jars in-memory, which doesn't create temporary copy, but is more memory consuming. Currently JBoss Enterprise Application Platform forces temporary copy by default.
+ This defines how nested jars should be handled. If forceCopy equals true, we create a temporary copy of the nested jar, and re-wire VFS accordingly. If forceCopy equals false, we handle nested jars in-memory, which doesn't create temporary copy, but is more memory consuming. Currently JBoss Enterprise Web Platform forces temporary copy by default.
</para>
<para>
If the <property>useCopyJarHandler</property> property is used as part of URI query, you can configure force-copy at runtime, per URI root (if it doesn't already exist).
@@ -312,7 +312,7 @@
</listitem>
</itemizedlist>
<para>
- In the JBoss Enterprise Application Platform we use <classname>CombinedVFSCache</classname> as we know which are our permanent roots to watch and keep.
+ In the JBoss Enterprise Web Platform we use <classname>CombinedVFSCache</classname> as we know which are our permanent roots to watch and keep.
This is how it's configured in MC's bean configuration file.
</para>
<programlisting><![CDATA[
@@ -409,10 +409,10 @@
Resource limits set by your operating system may also set limits on your database management system. A database administrator can analyze a database and identify performance bottlenecks through taking the above factors into consideration and adjusting the necessary database management system parameters such as writing dirty buffers to disk, checkpoints and log file rotations. In some instances hardware upgrades may also be necessary to improve database performance.
</para>
<para>
- Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss Enterprise Application Platform by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception.
+ Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss Enterprise Web Platform by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception.
</para>
<para>
- We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss Enterprise Application Platform and utilizing the connection pool settings. Connection pooling in the JBoss Enterprise Application Platform allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections.
+ We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss Enterprise Web Platform and utilizing the connection pool settings. Connection pooling in the JBoss Enterprise Web Platform allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections.
</para>
<para>
Depending on the databases implemented, please ensure you create a data source file in the deploy directory of your configuration as shown below:
@@ -426,7 +426,7 @@
<note><title>Note</title>
<para>
- Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss Enterprise Application Platform to recognize it as a <emphasis>data source file</emphasis>. The PostgreSQL database data source file for example is named <filename>postgres-ds.xml</filename>.
+ Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss Enterprise Web Platform to recognize it as a <emphasis>data source file</emphasis>. The PostgreSQL database data source file for example is named <filename>postgres-ds.xml</filename>.
</para>
</note>
@@ -444,13 +444,13 @@
<section>
<title>Ensuring Adequate Network Buffers</title>
- <para>The standard clustered services in the Enterprise Application Platform use UDP for intra-cluster communication, in order to take advantage of UDP-based IP multicast.
+ <para>The standard clustered services in the Enterprise Web Platform use UDP for intra-cluster communication, in order to take advantage of UDP-based IP multicast.
A downside to the use of UDP is some of the lossless transmission guarantees that are provided at the OS network level with TCP instead need to be implemented in Java code.
In order to achieve peak performance it is important to reduce the frequency of UDP packets being dropped in the network layers. A frequent cause of lost
- packets is inadequately sized network buffers on the machines that are hosting the cluster nodes. The Enterprise Application Platform clustering code will <emphasis>request</emphasis>
+ packets is inadequately sized network buffers on the machines that are hosting the cluster nodes. The Enterprise Web Platform clustering code will <emphasis>request</emphasis>
adequately sized read and write buffers from the OS when it opens sockets, but most operating systems (Windows seems to be an exception) will only <emphasis>provide</emphasis> buffers
up to a maximum size. This maximum read and write buffer sizes are configurable at the OS level, and the default values are too low to allow peak performance. So, a simple tuning step
- is to configure your OS to allow buffers up to the size the Enterprise Application Platform clustering code will request.</para>
+ is to configure your OS to allow buffers up to the size the Enterprise Web Platform clustering code will request.</para>
<para>The specific configuration steps needed to increase the maximum allowed buffer sizes are OS specific. See your OS documentation for instructions
on how to increase these. For Linux systems, maximum values for these buffers sizes that will survive machine restarts can be set by editing
@@ -467,17 +467,17 @@
<title>Isolating Intra-Cluster Traffic</title>
<para>If network resources are a bottleneck for your application, overall performance can be improved by isolating intra-cluster traffic from external request traffic.
This requires multiple NICs on your server machines, with request traffic coming in on one NIC and intra-cluster traffic using another. Once you
- have the hardware set up, it is easy to tell the Enterprise Application Platform nodes to use a different interface for the intra-cluster traffic:</para>
+ have the hardware set up, it is easy to tell the Enterprise Web Platform nodes to use a different interface for the intra-cluster traffic:</para>
<screen>./run.sh -c all -b 10.0.0.104 -Djgroups.bind_addr=192.168.100.104</screen>
- <para>In the above example, the <literal>-Djgroups.bind_addr</literal> setting tells the the Enterprise Application Platform to run intra-cluster JGroups traffic
+ <para>In the above example, the <literal>-Djgroups.bind_addr</literal> setting tells the the Enterprise Web Platform to run intra-cluster JGroups traffic
over the 192.168.100.104 interface, with <literal>-b</literal> specifying that all other traffic should use 10.0.0.104.</para>
</section>
<section>
<title>JGroups Message Bundling</title>
- <para>The JGroups group communication library used by the Enterprise Application Platform provides a feature known as "message bundling". Message
+ <para>The JGroups group communication library used by the Enterprise Web Platform provides a feature known as "message bundling". Message
bundling is similar to nagling on a TCP socket — small messages are queued before sending (for up to a configurable maximum time) until a configurable number
of bytes have accumulated, and then the queued messages are bundled and sent as one large message. Use of bundling can have significant performance benefits
for high-volume asynchronous session replication. However, it is not enabled by default, as bundling can add significant latency to other types of intra-cluster
@@ -508,7 +508,7 @@
<note>
<para>Using the <literal>udp-async</literal> JGroups protocol stack for the session caches means an additional JGroups transport protocol will be used.
- This means additional sockets will be opened compared to a standard Enterprise Application Platform installation.</para>
+ This means additional sockets will be opened compared to a standard Enterprise Web Platform installation.</para>
</note>
</section>
@@ -591,7 +591,7 @@
<section>
<title>Monitoring JGroups via JMX</title>
- <para>When the Enterprise Application Platform clustering services create a JGroups <literal>Channel</literal>
+ <para>When the Enterprise Web Platform clustering services create a JGroups <literal>Channel</literal>
to use for intra-cluster communication, they also register with the JMX server a number of MBeans related to
that channel; one for the channel itself and one for each of its constituent protocols. For users
interested in monitoring the performance-related behavior of a channel, a number of MBean attributes
@@ -654,16 +654,16 @@
<section id="Other_Tuning">
<title>Other key configurations</title>
<para>
- Other key configurations required for performance tuning of your Enterprise Application Platform include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
+ Other key configurations required for performance tuning of your Enterprise Web Platform include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
</para>
<para>
- JBoss Enterprise Application Platform 5 has a robust thread pooling, that should be sized appropriately.
+ JBoss Enterprise Web Platform 5 has a robust thread pooling, that should be sized appropriately.
The server has a <filename>jboss-service.xml</filename> file in the <filename><JBoss_Home>/server/<your_configuration>/conf</filename> directory that defines the system thread pool.
There is a setting that defines the behavior if there isn't a thread available in the pool for execution. The default is to allow the calling thread to execute the task. You can monitor the queue depth of the system thread pool through the JMX Console, and determine from that if you need to make the pool larger.
</para>
<para>
- The new administration console can be used for configuring and managing different aspects of the Enterprise Application Platform environment.
+ The new administration console can be used for configuring and managing different aspects of the Enterprise Web Platform environment.
</para>
<para>
The <literal>default</literal> configuration is appropriate for development, but not necessarily for a production environment. In the default configuration, console logging is enabled. Console logging is ideal for development, especially within the IDE, as you get all the log messages to show in the IDE console view.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -103,7 +103,7 @@
</para>
<note><title>Note</title>
-<para>This is the only supported behaviour for <emphasis>"local"</emphasis> transactions. This element is deprecated in JBoss Enterprise Application Platform 5 where transaction stickiness is enabled by default. XA users can explicitly enable interleaving with <interleaving/> element.</para>
+<para>This is the only supported behaviour for <emphasis>"local"</emphasis> transactions. This element is deprecated in JBoss Enterprise Web Platform 5 where transaction stickiness is enabled by default. XA users can explicitly enable interleaving with <interleaving/> element.</para>
</note>
</section>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -24,7 +24,7 @@
invocations collocated in a single JVM, and implements multihomed
servers.</para>
- <para>In the Enterprise Application Platform, Remoting supplies the transport layer for the
+ <para>In the Enterprise Web Platform, Remoting supplies the transport layer for the
EJB2, EJB3, and Messaging subsystems. In each case, the configuration of
Remoting is largely predetermined and fixed, but there are times when it is
useful to know how to alter a Remoting configuration. </para>
@@ -44,7 +44,7 @@
to use a socket timeout of 10000 and to use JBoss Serialization. A Remoting
client can use an InvokerLocator to connect to a given server. </para>
-<para>In the Enterprise Application Platform, Remoting servers and clients are created far
+<para>In the Enterprise Web Platform, Remoting servers and clients are created far
below the surface and are accessible only through configuration files.
Moreover, when a SLSB, for example, is downloaded from the JNDI directory, it
comes with a copy of the InvokerLocator, so that it knows how to contact the
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Security.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Security.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Security.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,11 +4,11 @@
<chapter id="security">
<title>Security</title>
<indexterm><primary>Security</primary><secondary>JBossAS</secondary></indexterm>
- <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>Security</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Web Platform</primary><secondary>Security</secondary></indexterm>
<para>The JBoss security framework default implementation is based on JAAS. It implements standard J2EE authentication and authorization but also supports extended security models with <ulink url="http://wiki.jboss.org/wiki/Edit.jsp?page=SecurityProxy">SecurityProxy?</ulink> and <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityAssociation">SecurityAssociation</ulink> implementations. </para>
<para>JAAS based implementation enables pluggable authentication modules (PAMs) which is a way to integrate with existing authentication frameworks in your enterprise. </para>
-<section><title>Changes affecting Security in JBoss Enterprise Application Platform 5</title>
+<section><title>Changes affecting Security in JBoss Enterprise Web Platform 5</title>
<section><title>Web Layer</title>
<para>
@@ -86,7 +86,7 @@
</para>
</section>
-<section><title>Securing a Web Application in JBoss Enterprise Application Platform</title>
+<section><title>Securing a Web Application in JBoss Enterprise Web Platform</title>
<para>
Securing web resources basically involves setting some stuff in the web deployment descriptor, and in jboss-web.xml. You also have to do a little prep work to the server itself to configure a security domain for JBoss SX. These instructions assume that you have JBoss AS installed, and you have a server instance created with at least Tomcat included. The "default" instance is a good choice here. The variable ${JBOSS_HOME} refers to the location you extracted/installed JBoss AS to, and ${server_configuration} corresponds to the name of the server instance you are configuring for security. The first part of these instructions refers to setting up JBoss SX for security, and the second part deals with setting up the web application for security using basic authentication. You can access the instructions in the following section.
</para>
@@ -99,7 +99,7 @@
<para>
Open the <filename> ${JBOSS_HOME}/server/${server_configuration}/conf/login-config.xml</filename> file.
- This file sets up the configuration for the security domains available to applications running in the server. The file already has a few domains in there for some example/default resources, so you might want to look to those for inspiration. JBoss SX uses JAAS for the underlying security infrastructure, and JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain (just a name really) to a JAAS login module. JBoss Enterprise Application Platform comes packed with a few different login modules which you can find more information about on the JBoss SX wiki page at JBossSX.</para>
+ This file sets up the configuration for the security domains available to applications running in the server. The file already has a few domains in there for some example/default resources, so you might want to look to those for inspiration. JBoss SX uses JAAS for the underlying security infrastructure, and JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain (just a name really) to a JAAS login module. JBoss Enterprise Web Platform comes packed with a few different login modules which you can find more information about on the JBoss SX wiki page at JBossSX.</para>
</listitem>
<listitem>
<para>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,7 +4,7 @@
<title>Transaction Management</title>
<section>
<title>Overview</title>
- <para>Transaction support in JBoss Enterprise Application Platform is provided by JBossTS, a mature, modular,
+ <para>Transaction support in JBoss Enterprise Web Platform is provided by JBossTS, a mature, modular,
standards based, highly configurable transaction manager. By default the
server runs with the local-only JTA module of JBossTS installed. This module
provides an implementation of the standard JTA API for use by other internal
@@ -12,7 +12,7 @@
code. It is suitable for coordinating ACID transactions that involve one or
more XA Resource managers, such as databases or message queues.</para>
<para>Two additional, optional, JBossTS transaction modules are also shipped with
- JBoss Enterprise Application Platform and may be deployed to provide additional functionality if
+ JBoss Enterprise Web Platform and may be deployed to provide additional functionality if
required. These are:</para>
<itemizedlist>
<listitem>
@@ -216,7 +216,7 @@
implementations, which are provided by the various resource managers. In
most instances, resource managers will be databases, message queues or 3rd
party JCA resource adapters. The list of JDBC database drivers and servers
- certified for use with JBoss Enterprise Application Platform can be found on the redhat.com website. In
+ certified for use with JBoss Enterprise Web Platform can be found on the redhat.com website. In
addition there is a reasonable probability of any driver that complies with
the relevant standards functioning correctly. However, interpretation of the
XA specification does differ from one vendor to another, as does quality of
@@ -473,11 +473,11 @@
<section>
<title>Experimental Components</title>
<para> In addition to the supported components of JBossTS that ship as part of JBoss
- Enterprise Application Platform, there is ongoing feature work that may eventually find its way into
+ Enterprise Web Platform, there is ongoing feature work that may eventually find its way into
future releases of the product. Meanwhile these prototype components are
available via from the jboss.org community site. Users are cautioned that
there is no guarantee these will work correctly and nor are they covered by
- the Enterprise Application Platform support agreement. However, some of the advanced functionality
+ the Enterprise Web Platform support agreement. However, some of the advanced functionality
available may nevertheless be attractive to projects in the early stages of
development. Users downloading these prototypes must be aware of the
limitations concerning module compatibility, in accordance with the 'source
@@ -525,17 +525,17 @@
functionality.</para>
<para> The source code for JBossTS can be downloaded direct from the project's svn
repository at http://anonsvn.jboss.org/repos/labs/labs/jbosstm/ To find the
- version matching the binaries in JBoss Enterprise Application Platform, consult your server logs. At
+ version matching the binaries in JBoss Enterprise Web Platform, consult your server logs. At
startup the server prints a string similar to:</para>
<para>INFO [TransactionManagerService] JBossTS Transaction Service (JTA version -
tag:JBOSSTS_4_6_1_GA_CP02) - JBoss Inc.</para>
<para>The value given for the tag corresponds to a tree under /tags/ in the svn
repository. Note that the version refers to the JBossTS releases consumed by
- Enterprise Application Platform, not the Enterprise Application Platform release numbering. Users building the Enterprise Application Platform from source may
+ Enterprise Web Platform, not the Enterprise Web Platform release numbering. Users building the Enterprise Web Platform from source may
also consult the version.jboss.jbossts value in
component-matix/pom.xml</para>
<para>Please note that installing any version of JBossTS other than those provided
- with the Enterprise Application Platform distribution or its CP releases is not supported. Also note
+ with the Enterprise Web Platform distribution or its CP releases is not supported. Also note
that, whilst some JBossTS components are packaged individually, it is not
supported to mix and match versions. i.e. do not run the JTA from one tag
with the XTS from another. API and functionality changes between releases
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -7,7 +7,7 @@
<para>
<indexterm><primary>JBoss5 Virtual Deployment Framework</primary><secondary>virtual deployment framework</secondary></indexterm>
<indexterm><primary>Virtual Deployment Framework</primary><see>JBoss5 Virtual Deployment Framework</see></indexterm>
- As indicated in <xref linkend="JBoss_Enterprise_Application_Platform_5_Introduction"/> the JBoss Enterprise Application Platform 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF). This chapter discusses the JBoss5 Virtual Deployment Framework further. The following UML diagram illustrates an overview of the key JBoss5 Deployment Framework classes.
+ As indicated in <xref linkend="JBoss_Enterprise_Application_Platform_5_Introduction"/> the JBoss Enterprise Web Platform 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF). This chapter discusses the JBoss5 Virtual Deployment Framework further. The following UML diagram illustrates an overview of the key JBoss5 Deployment Framework classes.
<figure id="JBoss5_virtual_deployment_framework_diagram">
<title>The JBoss5 Deployment Framework Classes</title>
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -16,7 +16,7 @@
A web service is essentially a software application that supports interaction of applications over a computer network or the world wide web. Web services usually interact through XML documents that map to an object, computer program, business process or database. To communicate, an application sends a message in XML document format to a web service which sends this message to the respective programs. Responses may be received based on requirements, the web service receives and then sends them in XML document format to the required program or applications. Web services can be used in many ways, examples include supply chain information management and business integration.
</para>
<para>
- JBossWS is a web service framework included as part of the JBoss Enterprise Application Platform. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5). Even though JAX-RPC is still supported (the web service specification for J2EE 1.4), JBossWS does put a clear focus on JAX-WS.
+ JBossWS is a web service framework included as part of the JBoss Enterprise Web Platform. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5). Even though JAX-RPC is still supported (the web service specification for J2EE 1.4), JBossWS does put a clear focus on JAX-WS.
</para>
<section><title>The need for web services</title>
<para>
@@ -547,7 +547,7 @@
}</programlisting>
<formalpara>
<title>WebServiceRef Customization</title>
- <para>In JBoss Enterprise Application Platform 5.0 we offer a number of overrides and extensions to the <classname>WebServiceRef</classname> annotation. These include:</para>
+ <para>In JBoss Enterprise Web Platform 5.0 we offer a number of overrides and extensions to the <classname>WebServiceRef</classname> annotation. These include:</para>
</formalpara>
<itemizedlist>
<listitem>
@@ -1103,7 +1103,7 @@
</note>
</para>
- <para>Let us create a POJO endpoint for deployment on JBoss Enterprise Application Platform. A simple <filename>web.xml</filename> needs to be created:</para>
+ <para>Let us create a POJO endpoint for deployment on JBoss Enterprise Web Platform. A simple <filename>web.xml</filename> needs to be created:</para>
<programlisting role="XML">
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml 2010-01-06 04:10:55 UTC (rev 99054)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml 2010-01-06 04:34:03 UTC (rev 99055)
@@ -4,7 +4,7 @@
<preface id="What_this_Book_Covers"><title>What this Book Covers</title>
<para>
- The primary focus of this book is the presentation of the standard JBoss Enterprise Application Platform 5.0 architecture components from both the perspective of their configuration and architecture. As a user of a standard JBoss distribution you will be given an understanding of how to configure the standard components. This book is not an introduction to JavaEE or how to use JavaEE in applications. It focuses on the internal details of the JBoss server architecture and how our implementation of a given JavaEE container can be configured and extended.
+ The primary focus of this book is the presentation of the standard JBoss Enterprise Web Platform 5.0 architecture components from both the perspective of their configuration and architecture. As a user of a standard JBoss distribution you will be given an understanding of how to configure the standard components. This book is not an introduction to JavaEE or how to use JavaEE in applications. It focuses on the internal details of the JBoss server architecture and how our implementation of a given JavaEE container can be configured and extended.
</para>
<para>
As a JBoss developer, you will be given a good understanding of the architecture and integration of the standard components to enable you to extend or replace the standard components for your infrastructure needs. We also show you how to obtain the JBoss source code, along with how to build and debug the JBoss server.
More information about the jboss-cvs-commits
mailing list