[jboss-cvs] JBossAS SVN: r99324 - 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 12 23:03:40 EST 2010
Author: laubai
Date: 2010-01-12 23:03:39 -0500 (Tue, 12 Jan 2010)
New Revision: 99324
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/Clustering_Guide_JBoss_Cache_JGroups.xml
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml
Log:
Partial edit of Clustering JBoss Cache JGroups chapter.
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-13 03:10:12 UTC (rev 99323)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2010-01-13 04:03:39 UTC (rev 99324)
@@ -7,7 +7,7 @@
<subtitle>for JBoss Enterprise Web Platform 5.0</subtitle>
<edition>1</edition>
<issuenum>1</issuenum>
- <pubsnumber>0.3</pubsnumber>
+ <pubsnumber>0.4</pubsnumber>
<productname>JBoss Enterprise Web Platform</productname>
<productnumber>5.0</productnumber>
<!-- <pubdate>, 2009</pubdate> -->
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-13 03:10:12 UTC (rev 99323)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-13 04:03:39 UTC (rev 99324)
@@ -179,154 +179,324 @@
</programlisting>
<!--hajime-->
<para>The available attributes in the above JGroups configuration are listed below.</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">ip_mcast</emphasis> specifies whether or not to use IP
- multicasting. The default is <literal>true</literal>. If set to false, it will send n unicast packets rather than 1 multicast packet. Either way, packets are UDP datagrams.
- </para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">mcast_addr</emphasis> specifies the multicast address (class D) for joining a group (i.e., the cluster). If omitted, the default is <literal>228.8.8.8
- </literal>.
- </para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">mcast_port</emphasis> specifies the multicast port number. If omitted, the
- default is <literal>45566</literal>.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">bind_addr</emphasis> specifies the interface on which to receive and send multicasts (uses the <literal>-Djgroups.bind_address</literal> system property, if present). If you have a multihomed machine, set the <literal>bind_addr</literal> attribute or system property to the appropriate NIC IP address. By default, system property setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr system property is set.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">receive_on_all_interfaces </emphasis> specifies whether this node
- should listen on all interfaces for multicasts. The default is <literal>false</literal>.
- It overrides the <literal>bind_addr</literal> property for receiving multicasts.
- However, <literal>bind_addr</literal> (if set) is still used to send multicasts.</para>
- </listitem>
- <listitem><para><emphasis role="bold">send_on_all_interfaces</emphasis> specifies whether this node send UDP packets via all the NICs if you have a multi NIC machine. This means that the same multicast message is sent N times, so use with care.
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">receive_interfaces</emphasis> specifies a list of of interfaces to receive multicasts on. The multicast receive socket will listen on all of these interfaces. This is a comma-separated list of IP addresses or interface names. E.g. "<literal>192.168.5.1,eth1,127.0.0.1</literal>".
- </para>
- </listitem>
-
-
- <listitem>
- <para><emphasis role="bold">ip_ttl</emphasis> specifies time-to-live for IP Multicast packets. TTL is the commonly used term in multicast networking, but is actually something of a misnomer, since the value here refers to how many network hops a packet will be allowed to travel before networking equipment will drop it.
- </para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">use_incoming_packet_handler</emphasis> specifies whether to use a separate thread to process incoming messages. Sometimes receivers are overloaded (they have to handle de-serialization etc). Packet handler is a separate thread taking care of de-serialization, receiver thread(s) simply put packet in queue and return immediately. Setting this to true adds one more thread. The default is <literal>true</literal>.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">use_outgoing_packet_handler</emphasis> specifies whether to use a separate thread to process outgoing messages. The default is false.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">enable_bundling</emphasis> specifies whether to enable message bundling.
- If it is <literal>true</literal>, the node would queue outgoing messages until
- <literal>max_bundle_size</literal> bytes have accumulated, or
- <literal>max_bundle_time</literal> milliseconds have elapsed, whichever occurs
- first. Then bundle queued messages into a large message and send it. The messages are
- unbundled at the receiver. The default is <literal>false</literal>.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">loopback</emphasis> specifies whether to loop outgoing message
- back up the stack. In <literal>unicast</literal> mode, the messages are sent to self. In
- <literal>mcast</literal> mode, a copy of the mcast message is sent. The default is <literal>false</literal></para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">discard_incompatibe_packets</emphasis> specifies whether to
- discard packets from different JGroups versions. Each message in the cluster is tagged
- with a JGroups version. When a message from a different version of JGroups is received,
- it will be discarded if set to true, otherwise a warning will be logged. The default is <literal>false</literal></para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">mcast_send_buf_size, mcast_recv_buf_size, ucast_send_buf_size,
- ucast_recv_buf_size</emphasis> define receive and send buffer sizes. It is good to
- have a large receiver buffer size, so packets are less likely to get dropped due to
- buffer overflow.</para>
- </listitem>
- <listitem>
- <para><literal>tos</literal> specifies traffic class for sending unicast and multicast datagrams.
- </para>
- </listitem>
-
- </itemizedlist>
+
+ <variablelist>
+ <varlistentry>
+ <term><varname>ip_mcast</varname></term>
+ <listitem>
+ <para>
+ Specifies whether IP multicasting is used. The default is <literal>true</literal>.
+ If set to <literal>false</literal>, unicast packets will be sent in place of one
+ multicast packet. In either case, packets are UDP datagrams.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>mcast_addr</varname></term>
+ <listitem>
+ <para>
+ Specifies the multicast address (class D) for joining a cluster. If omitted,
+ the default is <literal>228.8.8.8</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>mcast_port</varname></term>
+ <listitem>
+ <para>
+ Specifies the multicast port number. If omitted, the default is
+ <literal>45566</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>bind_addr</varname></term>
+ <listitem>
+ <para>
+ Specifies the interface on which to receive and send multicasts (uses the
+ <code>-Djgroups.bind_address</code> system property, if present). If you
+ have a multihomed machine, set the <varname>bind_addr</varname> attribute
+ or system property to the appropriate NIC IP address. By default, system
+ property has a higher priority than the XML attribute, unless the
+ <varname>-Djgroups.ignore.bind_addr</varname> system property is set.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>receive_on_all_interfaces</varname></term>
+ <listitem>
+ <para>
+ Specifies whether this node should listen on all interfaces for multicasts.
+ The default is <literal>false</literal>. This attribute overrides the
+ <varname>bind_addr</varname> property for receiving multicasts. However,
+ <varname>bind_addr</varname> (if set) is still used to send multicasts.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>send_on_all_interfaces</varname></term>
+ <listitem>
+ <para>
+ Specifies whether this node sends UDP packets via all NICs, if you have
+ a multi-NIC machine. This means that the same multicast message is sent
+ <emphasis>N</emphasis> times, so should be used with care.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>receive_interfaces</varname></term>
+ <listitem>
+ <para>
+ Specifies a comma-separated list of interfaces to receive multicasts on. The multicast
+ receive socket listens on all listed interfaces. Interfaces are specified by
+ IP address, for example, <literal>"192.168.5.1,eth1,127.0.0.1"</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>ip_ttl</varname></term>
+ <listitem>
+ <para>
+ Specifies the <emphasis>time to live</emphasis> (TTL) for IP multicast packets.
+ TTL is the common term in multicast networking, but the value actually refers to
+ how many network hops a packet will be allowed to travel before networking
+ equipment drops it.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>use_incoming_packet_handler</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to use a separate thread to process incoming messages. Receivers
+ can become overloaded when they handle deserialization, etc. Packet handlers are
+ separate threads that handle deserialization, where receiver threads simply place
+ a packet in a queue and return immediately. Setting this attribute to
+ <literal>true</literal> (the default value) adds one more thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>use_outgoing_packet_handler</varname></term>
+ <listitem>
+ <para>
+ Specifies whether a separate thread is used to process outgoing messages.
+ The default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>enable_bundling</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to emable message bundling. If <literal>true</literal>, the node
+ queues outgoing messages until either <varname>max_bundle_size</varname> bytes have
+ accumulated, or <varname>max_bundle_time</varname> milliseconds have elapsed. The
+ queued messages are then bundled into one large message, sent, and unbundled at
+ the receiver. The default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>loopback</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to loop outgoing messages back up the stack. In
+ <literal>unicast</literal> mode, a copy of the multicast message is sent. The
+ default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>discard_incompatible_packets</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to discard packets from different JGroups versions. Each message
+ in the cluster is tagged with a JGroups version. When a message from a different
+ version of JGroups is received, and this attribute is set to <literal>true</literal>,
+ it will be discarded. If set to <literal>false</literal> (the default), a warning
+ is logged.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>mcast_send_buf_size</varname>, <varname>mcast_recv_buf_size</varname>,
+ <varname>ucast_send_buf_size</varname>, <varname>ucast_recv_buf_size</varname></term>
+ <listitem>
+ <para>
+ Define the buffer sizes for receive and send operations. It is useful to have
+ a large buffer size so that packets are less likely to be dropped due to buffer overflow.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>tos</varname></term>
+ <listitem>
+ <para>
+ Specifies the traffic class used to send unicast and multicast datagrams.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<note>
- <para>On Windows 2000 machines, because of the media sense feature being broken with multicast
- (even after disabling media sense), you need to set the UDP protocol's
- <literal>loopback</literal> attribute to <literal>true</literal>.</para>
+ <title>Windows 2000</title>
+ <para>The media sense feature is broken with multicast, even when
+ media sense is disabled. On Windows 2000 machines, you must set the UDP protocol's
+ <varname>loopback</varname> attribute to <literal>true</literal>.</para>
</note>
</section>
-
+ <!--tsuzukeru-->
<section id="jbosscache-jgroups-transport-tcp">
<title>TCP configuration</title>
- <para>Alternatively, a JGroups-based cluster can also work over TCP connections. Compared with UDP,
- TCP generates more network traffic when the cluster size increases. TCP
- is fundamentally a unicast protocol. To send multicast messages, JGroups uses multiple TCP
- unicasts. To use TCP as a transport protocol, you should define a <literal>TCP</literal> element
- in the JGroups <literal>Config</literal> element. Here is an example of the
- <literal>TCP</literal> element.</para>
- <programlisting>
-<TCP start_port="7800"
+ <para>
+ A JGroups-based cluster can be used as an alternative over TCP connections. TCP
+ generates more network traffic than UDP as cluster size increases. Fundamentally,
+ TCP is a unicast protocol. To send multicast messages, JGroups uses multiple TCP
+ unicasts. To use TCP as a transport protocol, you should define a
+ <literal>TCP</literal> element in the JGroups <literal>Config</literal> element,
+ like so:
+ </para>
+ <programlisting><![CDATA[
+<TCP start_port="7800"
bind_addr="192.168.5.1"
loopback="true"
- down_thread="false" up_thread="false"/>
+ down_thread="false" up_thread="false"/>]]>
</programlisting>
- <para>Below are the attributes available in the <literal>TCP</literal> element.</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">bind_addr</emphasis> specifies the binding address. It can also
- be set with the <literal>-Djgroups.bind_address</literal> command line option at server
- startup.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">start_port, end_port</emphasis> define the range of TCP ports
- the server should bind to. The server socket is bound to the first available port from
- <literal>start_port</literal>. If no available port is found (e.g., because of a
- firewall) before the <literal>end_port</literal>, the server throws an exception. If no <literal>end_port</literal> is provided or <literal>end_port < start_port</literal> then there is no upper limit on the port range. If <literal>start_port == end_port</literal>, then we force JGroups to use the given port (start fails if port is not available). The default is 7800. If set to 0, then the operating system will pick a port. Please, bear in mind that setting it to 0 will work only if we use MPING or TCPGOSSIP as discovery protocol because <literal>TCCPING</literal> requires listing the nodes and their corresponding ports.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">loopback</emphasis> specifies whether to loop outgoing message
- back up the stack. In <literal>unicast</literal> mode, the messages are sent to self. In
- <literal>mcast</literal> mode, a copy of the mcast message is sent. The default is false.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">recv_buf_size, send_buf_size</emphasis> define receive and send buffer sizes. It is good to have a large receiver buffer size, so packets are less likely to get dropped due to buffer overflow.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">conn_expire_time</emphasis> specifies the time (in milliseconds)
- after which a connection can be closed by the reaper if no traffic has been
- received.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">reaper_interval</emphasis> specifies interval (in milliseconds)
- to run the reaper. If both values are 0, no reaping will be done. If either value is
- > 0, reaping will be enabled. By default, reaper_interval is 0, which means no reaper.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">sock_conn_timeout</emphasis> specifies max time in millis for a socket creation. When doing the initial discovery, and a peer hangs, don't wait forever but go on after the timeout to ping other members. Reduces chances of *not* finding any members at all. The default is 2000.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">use_send_queues</emphasis> specifies whether to use separate send queues for each connection. This prevents blocking on write if the peer hangs. The default is true.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">external_addr</emphasis> specifies external IP address to broadcast to other group members (if different to local address). This is useful when you have use (Network Address Translation) NAT, e.g. a node on a private network, behind a firewall, but you can only route to it via an externally visible address, which is different from the local address it is bound to. Therefore, the node can be configured to broadcast its external address, while still able to bind to the local one. This avoids having to use the TUNNEL protocol, (and hence a requirement for a central gossip router) because nodes outside the firewall can still route to the node inside the firewall, but only on its external address. Without setting the external_addr, the node behind the firewall will broadcast its private address to the other nodes which will not be able to route to it.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">skip_suspected_members</emphasis> specifies whether unicast messages should not be sent to suspected members. The default is true.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">tcp_nodelay</emphasis> specifies TCP_NODELAY. TCP by default nagles messages, that is, conceptually, smaller messages are bundled into larger ones. If we want to invoke synchronous cluster method calls, then we need to disable nagling in addition to disabling message bundling (by setting <literal>enable_bundling</literal> to false). Nagling is disabled by setting <literal>tcp_nodelay</literal> to true. The default is false.
- </para>
- </listitem>
-
- </itemizedlist>
+ <para>Below are the attributes available to the <literal>TCP</literal> element.</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><varname>bind_addr</varname></term>
+ <listitem>
+ <para>
+ Specifies the binding address. It can also be set with the
+ <code>-Djgroups.bind_address</code> command line option at server startup.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>start_port</varname>, <varname>end_port</varname></term>
+ <listitem>
+ <para>
+ These attributes define the range of TCP ports to which the server should bind.
+ The server socket is bound to the first available port from
+ <varname>start_port</varname>. If no available port is found before the
+ <varname>end_port</varname> (for example, because of a firewall), the server throws
+ an exception. If no <varname>end_port</varname> is provided, or the
+ <varname>end_port</varname> value is lower than the <varname>start_port</varname>
+ value, then there is no upper limit on the port range. If the
+ <varname>start_port</varname> value is equal to the <varname>end_port</varname> value,
+ JGroup is forced to use the specified port and start fails if the port is not available.
+ The default value is <literal>7800</literal>. If set to <literal>0</literal>, the
+ operating system will pick a port. (This is only possible if the discovery protocol
+ is <literal>MPING</literal> or <literal>TCPGOSSIP</literal>, because
+ <literal>TCPPING</literal> requires a list of nodes and their corresponding ports.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>loopback</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to loop an outgoing message back up the stack. In unicast mode,
+ the message is sent itself. In multicast mode, a copy of the message is sent. The
+ default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>recv_buf_size</varname>, <varname>send_buf_size</varname></term>
+ <listitem>
+ <para>
+ Define the buffer size for receive and send operations. Large buffer sizes
+ mean that packets are less likely to be dropped due to buffer overflow.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>conn_expire_time</varname></term>
+ <listitem>
+ <para>
+ Specifies the time in milliseconds after which a connection can be closed
+ by the reaper if no traffic has been received.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>reaper_interval</varname></term>
+ <listitem>
+ <para>
+ Specifies the interval in milliseconds at which the reaper should be run. If both
+ values are <literal>0</literal>, no reaping will be done. If either value is
+ greater than zero, reaping will be enabled. By default, <varname>reaper_interval</varname>
+ is set to <literal>0</literal> (no reaper).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>sock_conn_timeout</varname></term>
+ <listitem>
+ <para>
+ Specifies the maximum time period for socket creation in milliseconds.
+ If a peer hangs during the initial discovery, the master node moves on to ping
+ other cluster members after this timeout period. This reduces the chances of not
+ finding any cluster members. The default value is <literal>2000</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>use_send_queues</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to use separate send queues for each connection. This prevents
+ blocking on write if the peer hangs. The default value is <literal>true</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>external_addr</varname></term>
+ <listitem>
+ <para>
+ Specifies the external IP address to broadcast to other group members (if not the
+ local address). This is particularly useful when Network Address Translation (NAT)
+ is in use, for example, when a node on a private network behind a firewall can only
+ be routed to via an externally visible address different to the local address to
+ which it is bound. The node can be configured to broadcast its external address while
+ remaining able to bind to the local address. This lets you avoid using TUNNEL protocol,
+ since nodes outside the firewall can still route to the node inside the firewall, but
+ only on its external address. If <varname>external_addr</varname> is not set, the node
+ behind the firewall will broadcast its private address to other nodes, which will not
+ be able to route to it.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>skip_suspected_members</varname></term>
+ <listitem>
+ <para>
+ Specifies that suspected members will not receive unicast messages. The default
+ value is <literal>true</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>tcp_nodelay</varname></term>
+ <listitem>
+ <para>
+ Specifies <literal>TCP_NODELAY</literal>. By default, TCP <emphasis>nagles</emphasis>
+ messages (bundles smaller messages together into a larger message). To invoke
+ synchronous cluster method calls, we must disable nagling in addition to disabling
+ message bundling. To do this, set <varname>tcp_nodelay</varname> to <literal>true</literal>
+ and <varname>enable_bundling</varname> to <literal>false</literal>. The default value
+ for <varname>tcp_nodelay</varname> is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
-
+ <!--hajime-->
<section id="jbosscache-jgroups-transport-tunnel">
<title>TUNNEL configuration</title>
<para>The TUNNEL protocol uses an external router to send messages. The external router is known as
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml 2010-01-13 03:10:12 UTC (rev 99323)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml 2010-01-13 04:03:39 UTC (rev 99324)
@@ -8,8 +8,8 @@
<simpara>
<revhistory>
<revision>
- <revnumber>1.4</revnumber>
- <date>Tue Jan 12 2010</date>
+ <revnumber>1.5</revnumber>
+ <date>Wed Jan 13 2010</date>
<author>
<firstname>Laura</firstname>
<surname>Bailey</surname>
More information about the jboss-cvs-commits
mailing list