[jboss-cvs] JBoss Messaging SVN: r8054 - projects/enterprise/EAP/trunk/5.x/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Jun 2 03:26:45 EDT 2010
Author: jaredmorgs
Date: 2010-06-02 03:26:44 -0400 (Wed, 02 Jun 2010)
New Revision: 8054
Modified:
projects/enterprise/EAP/trunk/5.x/en-US/Bridge.xml
projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml
projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml
Log:
Updated the Clustering section with links to relevant parts of the guide to avoid duplication
Modified: projects/enterprise/EAP/trunk/5.x/en-US/Bridge.xml
===================================================================
--- projects/enterprise/EAP/trunk/5.x/en-US/Bridge.xml 2010-06-02 07:20:45 UTC (rev 8053)
+++ projects/enterprise/EAP/trunk/5.x/en-US/Bridge.xml 2010-06-02 07:26:44 UTC (rev 8054)
@@ -1,104 +1,83 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version='1.0' encoding='UTF-8'?>
<chapter id="bridge">
<title>JBoss Messaging Message Bridge Configuration</title>
-
- <section id="bridge.overview">
+ <section id="sect-Message_Bridge_Overview">
<title>Message Bridge Overview</title>
-
<para>
JBoss Messaging includes a fully functional message bridge.
</para>
-
<para>
The bridge consumes messages from a source queue or topic and sends them to a target queue or topic, typically on a different server. The source and target servers need not be in the same cluster, so bridging is a reliable method of sending messages from one cluster to another (across a WAN, for example) and where the connection may be unreliable.
</para>
-
<para>
A bridge is deployed as a managed bean within any JBoss Application Server instance. To deploy, simply add the managed bean descriptor into the <filename>deploy</filename> directory of an Enterprise Application Platform configuration that contains JBoss Messaging.
</para>
-
<para>
The example in <filename>/doc/examples/jboss-messaging-examples/bridge/</filename> demonstrates a simple bridge deployed in JBoss Application Server and moving messages from the source to the target destination.
</para>
-
<para>
The bridge can also be used to retrieve messages from other non-JBoss Messaging JMS servers as long as they are JMS 1.1 compliant.
</para>
-
<para>
The bridge has built-in resistence to failure, so if the source or target server connection is lost, the bridge will attempt to reconnect to the source or target until it comes back online, at which point normal operation will resume.
</para>
-
<para>
The bridge can be configured to consume messages matching a particular JMS selector.
</para>
-
<para>
It can be configured to consume from a queue or a topic. When the bridge consumes from a topic, it can be configured to consume with a non-durable or a durable subscription.
</para>
-
<para>
The bridge can be configured to bridge messages with one of three <emphasis>quality of service</emphasis> levels:
</para>
-
<itemizedlist>
- <listitem>
- <para><literal>QOS_AT_MOST_ONCE</literal></para>
-
- <para>
+ <listitem>
+ <para><literal>QOS_AT_MOST_ONCE</literal></para>
+ <para>
This mode specifies that messages will arrive at the destination once at the most. Messages are consumed from the source and acknowledged before they are sent to the destination. Therefore, if failure occurs between the message leaving the source and arriving at the destination, messages can be lost. Messages will therefore be delivered once at most. This mode is available for both persistent and non-persistent messages.
</para>
- </listitem>
-<!--hajime-->
- <listitem>
- <para><literal>QOS_DUPLICATES_OK</literal></para>
-
- <para>
+ </listitem>
+<!--hajime--> <listitem>
+ <para><literal>QOS_DUPLICATES_OK</literal></para>
+ <para>
This mode specifies that messages are consumed from the source and acknowledged after they have been successfully sent to the destination. Therefore, if failure occurs between a message arriving at the destination and being acknowledged by the destination, that message may be sent a second time when the system recovers, so the destination may receive duplicate messages. This mode is available for both persistent and non-persistent messages.
</para>
- </listitem>
-
- <listitem>
- <para><literal>QOS_ONCE_AND_ONLY_ONCE</literal></para>
-
- <para>
+ </listitem>
+ <listitem>
+ <para><literal>QOS_ONCE_AND_ONLY_ONCE</literal></para>
+ <para>
This mode specifies that messages will arrive exactly once. When the message source and destination are on the same JBoss Messaging server instance, the message can be sent and received in the same local transaction. If the source and destination are on different servers, you can enlist the sending and consuming sessions in a JTA transaction controlled by JBoss Transactions JTA implementation, which provides high durability. If JTA is required, both connection factories must be <literal>XAConnectionFactory</literal> implementations.
</para>
- <para>
+ <para>
This mode is only available for persistent messages.
</para>
- <para>
+ <para>
Because this mode requires logging on both the transaction manager and the resource side to support recovery, it will likely be the slowest mode. If you require this level of quality of service, you must enable XA Recovery with JBoss Transactions.
</para>
- <note>
- <title>Alternative Methods</title>
- <para>
+ <note>
+ <title>Alternative Methods</title>
+ <para>
You may be able to apply <emphasis>once and only once</emphasis> semantics to a specific application without setting <literal>QOS_ONCE_AND_ONLY_ONCE</literal>. Set <literal>QOS_DUPLICATES_OK</literal> mode, and then check for and discard duplicate messages at the destination. You may be able to implement this at the application level by maintaining a cache of received message IDs on disk and comparing received messages to this cache. Since the cache would only be valid for a certain period of time, this approach is not infallible, but can be a useful alternative depending on your application.
</para>
- </note>
- </listitem>
- </itemizedlist>
+ </note>
+ </listitem>
+ </itemizedlist>
</section>
-
<section id="bridge.deployment">
<title>Bridge deployment</title>
-
<para>
You can deploy a message bridge by adding a managed bean descriptor into the <filename>deploy</filename> directory of the JBoss Application Server installation that contains JBoss Messaging.
</para>
</section>
-
<section id="bridge.configuration">
<title>Bridge Configuration</title>
-
<para>
This section shows you how to configure the message bridge.
</para>
<para>
The following code is an example configuration of the message bridge, showing all attributes. Some attributes have been commented out for this configuration, since not all attributes should be specified at once.
</para>
-
-<programlisting><![CDATA[
+ <programlisting><![CDATA[
<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=Bridge,name=TestBridge"
xmbean-dd="xmdesc/Bridge-xmbean.xml">
@@ -187,14 +166,11 @@
</mbean>
]]></programlisting>
-
- <para>
+ <para>
The next section discusses these attributes in detail.
</para>
-
<section id="bridge.configuration.sourceproviderloader">
<title>SourceProviderLoader</title>
-
<para>
The <literal>JMSProviderLoader</literal> managed bean that the bridge uses to look up the source connection factory and source destination. By default, JBoss Application Server ships with one <literal>JMSProviderLoader</literal>, which is deployed in the <filename>jms-ds.xml</filename> file, and serves as the default local <literal>JMSProviderLoader</literal>. (A clustered configuration would use <filename>hajndi-jms-ds.xml</filename>.)
</para>
@@ -205,10 +181,8 @@
If you want to use <emphasis>once and only once</emphasis> delivery and you are using a remote non-JBoss Messaging source or target, the remote JMS Provider must provide a fully-functional JMS XA resource implementation that works remotely from the server.
</para>
</section>
-
<section id="bridge.configuration.targetproviderloader">
<title>TargetProviderLoader</title>
-
<para>
The <literal>JMSProviderLoader</literal> managed bean used by the bridge to lookup the target connection factory and target destination. By default, JBoss Application Server ships with one <literal>JMSProviderLoader</literal>, which is deployed in the <filename>jms-ds.xml</filename> file, and serves as the default local <literal>JMSProviderLoader</literal>. (A clustered configuration would use <filename>hajndi-jms-ds.xml</filename>.)
</para>
@@ -219,58 +193,44 @@
If you want to use <emphasis>once and only once</emphasis> delivery and you are using a remote non-JBoss Messaging source or target, the remote JMS Provider must provide a fully-functional JMS XA resource implementation that works remotely from the server.
</para>
</section>
-
<section id="bridge.configuration.sourcedestinationlookup">
<title>SourceDestinationLookup</title>
-
<para>
The full JNDI lookup for the source destination, via the <literal>SourceProviderLoader</literal>, such as <filename>/queue/mySourceQueue</filename>.
</para>
</section>
-
<section id="bridge.configuration.targetdestinationlookup">
<title>TargetDestinationLookup</title>
-
<para>
The full JNDI lookup for the target destination, via the <literal>TargetProviderLocator</literal>, such as <filename>/topic/myTargetTopic</filename>.
</para>
</section>
-
<section id="bridge.configuration.sourceusername">
<title>SourceUsername</title>
-
<para>
An optional attribute that specifies the username used when creating the source connection.
</para>
</section>
-
<section id="bridge.configuration.sourcepassword">
<title>SourcePassword</title>
-
<para>
An optional attribute that specifies the password used when creating the source connection.
</para>
</section>
-
<section id="bridge.configuration.targetusername">
<title>TargetUsername</title>
-
<para>
An optional attribute that specifies the username used when creating the raget connection.
</para>
</section>
-
<section id="bridge.configuration.targetpassword">
<title>TargetPassword</title>
-
<para>
An optional attribute that specifies the password used when creating the target connection.
</para>
</section>
-
<section id="bridge.configuration.qualityofservicemode">
<title>QualityOfServiceMode</title>
-
<para>
An integer representing the desired <emphasis>quality of service</emphasis> mode. The possible values are:
</para>
@@ -292,72 +252,56 @@
</listitem>
</itemizedlist>
<para>
- See <xref linkend="bridge.overview" /> for a complete explanation of these modes.
+ See <xref linkend="bridge.overview"/> for a complete explanation of these modes.
</para>
</section>
-
<section id="bridge.configuration.selector">
<title>Selector</title>
-
<para>
- An optional attribute that lets you provide a JMS selector expression when consuming messages from a source destination. Only messages that match the selector expression are bridged from the source to the target destination. The selector expression must follow the JMS selector syntax, specified here: <ulink url="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html" />.
+ An optional attribute that lets you provide a JMS selector expression when consuming messages from a source destination. Only messages that match the selector expression are bridged from the source to the target destination. The selector expression must follow the JMS selector syntax, specified here: <ulink url="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html"/>.
</para>
<para>
For optimal performance, apply source topic subscription selectors to source queue consumers.
</para>
</section>
-
<section id="bridge.configuration.maxbatchsize">
<title>MaxBatchSize</title>
-
<para>
Specifies the maximum number of messages to consume from the source destination before sending a message batch to the target destination. Its value must be greater than or equal to <literal>1</literal>.
</para>
</section>
-
<section id="bridge.configuration.maxbatchtime">
<title>MaxBatchTime</title>
-
<para>
Specifies the longest period (in milliseconds) to wait before sending a message batch to the target, even if the <varname>MaxBatchSize</varname> has not been reached. Its value must be either <literal>-1</literal> (wait forever) or greater than or equal to <literal>1</literal> to specify a time.
</para>
</section>
-
<section id="bridge.configuration.subname">
<title>SubName</title>
-
<para>
Represents the name of the durable subscription that will consume from the source destination topic.
</para>
</section>
-
<section id="bridge.configuration.clientid">
<title>ClientID</title>
-
<para>
Represents the JMS client ID to use when creating or looking up the durable subscription that will consume from the source destination topic.
</para>
</section>
-
<section id="bridge.configuration.failureretryinterval">
<title>FailureRetryInterval</title>
-
<para>
The period of time (in milliseconds) to wait between attempting to recreate the connection to the source or target server after failure is detected.
</para>
</section>
-
<section id="bridge.configuration.maxretries">
<title>MaxRetries</title>
-
<para>
The number of times to attempt to recreate the connection to the source or target server after failure is detected. The bridge will then stop attempting to recreate the connection. A value of <literal>-1</literal> means that the bridge will continue to attempt to reconnect forever.
</para>
</section>
-
<section id="bridge.configuration.addmessageidinheader">
<title>AddMessageIDInHeader</title>
-
<para>
When <literal>true</literal>, the original message ID is added to the <literal>JBossMessage.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST</literal> header of the message being sent to the destination. If the message is bridged multiple times, each message ID is added to the header. This enables a distributed request-response pattern.
</para>
Modified: projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml
===================================================================
--- projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml 2010-06-02 07:20:45 UTC (rev 8053)
+++ projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml 2010-06-02 07:26:44 UTC (rev 8054)
@@ -1,75 +1,77 @@
<?xml version='1.0' encoding='UTF-8'?>
<chapter id="c_configuration">
<title>Clustering Notes</title>
- <section id="c_conf.serverpeerid">
+ <para>Rather than grouping disparate clustering information in a dedicated section of the guide, relevant information and caveats are co-located as close to the information as possible. To assist you locating important clustering-related information, a summary of each consideration is provided in this part of the guide with links to the related components of JBoss Messaging. </para>
+ <section id="sect-Unique_Server_Peer_ID">
<title>Unique Server Peer ID</title>
- <para>In most cases, JBoss Messaging works in a clustered environment with minimal configuration changes. One crucial change that must be made is that every node is assigned a unique server ID, as specified in the Installation Guide.
+ <para><!--Relocate: This information should be aligned in the ServerPeerID attribute in 6.2, ServerPeer Attributes.-->In most cases, JBoss Messaging works in a clustered environment with minimal configuration changes. One crucial change that must be made is that every node is assigned a unique server ID.
</para>
<para>
Every deployed node must have a unique ID, including nodes that form a LAN cluster and nodes linked by message bridges.
</para>
+ <para>The <parameter>ServerPeerID</parameter> attribute is used to set this information. Refer to <xref linkend="sect-ServerPeer_Attributes"/> for further information.</para>
</section>
- <section id="c_conf.clustereddests">
+ <section id="sect-Clustered_Destinations">
<title>Clustered Destinations</title>
- <para>
- JBoss Messaging clusters Java Message Service (JMS) queues and topics transparently across the cluster. Messages sent to a distributed queue or topic on one node are consumable on other nodes. To make a particular destination clustered, set the <varname>clustered</varname> attribute in the destination Deployment Descriptor to <literal>true</literal>.
+ <para><!--Relocate: This paragraph should be integrated into 6.4.1 Post Office Attributes-->
+ JBoss Messaging clusters Java Message Service (JMS) queues and topics transparently across the cluster. Messages sent to a distributed queue or topic on one node are consumable on other nodes. To make a particular destination clustered, The <varname>clustered</varname> attribute is used to set this functionality. Refer to <xref linkend="sect-Post_Office_Attributes"/> for further information.
</para>
<para>
- JBoss Messaging balances messages between nodes and caters for consumers of varying speeds so that processing load is distributed efficiently across the cluster.
+ <!--Relocate: The following two paras need to be located near the ClusterPullConnectionFactoryName description in 6.1 Configuring the Server Peer-->JBoss Messaging balances messages between nodes and caters for consumers of varying speeds so processing load can be efficiently distributed across the cluster.
</para>
<para>
- To disable message redistribution between nodes while retaining other characteristics of clustered destinations, do not specify the <varname>ClusterPullConnectionFactoryName</varname> attribute on the Server Peer.
+ To disable message redistribution between nodes while retaining other characteristics of clustered destinations, do not specify the <varname>ClusterPullConnectionFactoryName</varname> attribute on the Server Peer (refer to <xref linkend="sect-ServerPeer_Attributes"/> for full details about this attribute.
</para>
</section>
<section id="c_conf.clustereddursubs">
- <title>Clustered durable subscriptions</title>
- <para>
+ <title>Clustered Durable Subscriptions</title>
+ <para><!--Relocate: This informaiton needs to go into 2.1 JBoss Messaging Features under the "Fully-clustered durable subscriptions" varlistitem-->
It is also possible to cluster JBoss Messaging durable subscriptions such that multiple subscribers on multiple nodes can consume from one durable subscription. A durable subscription will be clustered if its topic is clustered.
</para>
+ <para>For more information about configuring clustered topics and queues, refer to the <parameter>Clustered</parameter> attribute in <xref linkend="sect-Post_Office_Attributes"/></para>
</section>
<section id="c_conf.clusteredtempdest">
- <title>Clustered temporary destinations</title>
- <para>
+ <title>Clustered Temporary Destinations</title>
+ <para><!--Relocate: Include this information in 2.1 JBoss Messaging Features under "Fully-clustered temporary queues" and link to the PostOffice configuration section.-->
JBoss Messaging supports clustering of temporary topics and queues. All temporary topics and queues will be clustered if the Post Office is clustered.
</para>
+ <para>For more information about configuring clustered topics and queues, refer to the <parameter>Clustered</parameter> attribute in <xref linkend="sect-Post_Office_Attributes"/>.</para>
</section>
<section id="c_conf.nonclusteredserver">
- <title>Non-clustered servers</title>
- <para>
+ <title>Non-clustered Servers</title>
+ <para><!--Relocate: Add this information to the "Clustered" attribute.-->
Set the <literal>PostOffice</literal>'s <varname>clustered</varname> attribute to <literal>false</literal> if you do not want all nodes to participate in a cluster, or if you do not want the server to be clustered.
</para>
+ <para>For more information about configuring non-clustered server, refer to the various attributes in <xref linkend="sect-Post_Office_Attributes"/>.</para>
</section>
<section id="c_conf.orderingincluster">
- <title>Message ordering in the cluster</title>
- <para>
- To apply strict JMS ordering to messages such that messages are consumed in the same order they were produced, set the <varname>DefaultPreserveOrdering</varname> Server Peer attribute to <literal>true</literal>. (The default value is <literal>false</literal>.) While set to <literal>true</literal>, messages cannot be distributed as freely around the cluster.
+ <title>Message Ordering in the Cluster</title>
+ <para><!--Relocate: This info needs to go into 6.2 ServerPeer Attributes "DefaultPreserve Ordering" as a Clustering Note-->
+ You can apply strict JMS ordering to messages so that messages are consumed in the same order they were produced. The <varname>DefaultPreserveOrdering</varname> Server Peer controls this functionality. Refer to <xref linkend="sect-ServerPeer_Attributes"/> for detailed information.
</para>
</section>
<section id="c_conf.idempotentops">
- <title>Idempotent operations</title>
+ <title>Idempotent Operations</title>
<para>
- If the call to send a persistent message to a persistent destination returns with no exception, then they message has definitely been persisted. However, if an exception is thrown, you cannot be certain that the message was <emphasis>not</emphasis> persisted, because failure may have occurred between the message being persisted and a response being returned to the caller.
+ If the call to send a persistent message to a persistent destination returns with no exception, then the message has definitely been persisted. </para>
+ <para>If an exception is thrown however, you cannot guarantee the message was <emphasis>not</emphasis> persisted, because failure may have occurred between the message being persisted and a response being returned to the caller.
</para>
- <para>
- Your applications must therefore be coded so that its operations are <emphasis>idempotent</emphasis> — that is, they can be repeated without causing the system to become inconsistent.
+ <para>Your applications must therefore be coded so that its operations are <emphasis>idempotent</emphasis> — that is, they can be repeated without causing the system to become inconsistent.
</para>
- <para>
- In a messaging system, you can do this on the application level by checking for duplicate messages and discarding them if the original message has been sent successfully. This <emphasis>duplicate checking</emphasis> is a powerful technique that can remove the need for XA transactions.
+ <para>You can implement this behaviour on the application level by checking for duplicate messages and discarding them if the original message has been sent successfully. This <emphasis>duplicate checking</emphasis> is a powerful technique that can remove the need for XA transactions.
</para>
- <para>
- In a clustered environment, JBoss Messaging is configured to perform duplicate checking by default.
+ <para>JBoss Messaging is configured by default to perform duplicate checking in a clustered environment.
</para>
+ <para>Persistence considerations are located in <xref linkend="sect-Managed_Beans_In_The_ServerPeer"/>, <xref linkend="sect-Changing_The_Database"/>, <xref linkend="sect-Configuring_The_Persistence_Manager"/>, and <xref linkend="sect-Message_Bridge_Overview"/>.</para>
</section>
<section id="c_conf.clusteredcfs">
<title>Clustered connection factories</title>
<para>
- When <varname>supportsLoadBalancing</varname> is set to <literal>true</literal>, consecutive attempts to create connections will round-robin between available servers. The first node is chosen randomly.
+ <!--Relocate: Need a link to 6.8.1. ConnectionFactory Managed Bean Attributes for this section-->When <varname>supportsLoadBalancing</varname> is set to <literal>true</literal> in the connection factory, consecutive attempts to create connections will round-robin between available servers. The first node is chosen randomly.
</para>
<para>
When <varname>supportsFailover</varname> is set to <literal>true</literal>, failover will occur transparently and automatically whenever any connection error is detected.
</para>
- <para>
- If automatic failover is not required, set <varname>supportsFailover</varname> to <literal>false</literal> and provide a standard JMS <literal>ExceptionListener</literal> to be called in case of server failure. Following server failure, you will need to manually close the connection, lookup a new connection factory from HAJNDI, and create a new connection.
- </para>
+ <para>For more information about configuring connection factories, refer to <xref linkend="sect-ConnectionFactory_Managed_Bean_Attributes"/>.</para>
</section>
</chapter>
Modified: projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml
===================================================================
--- projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml 2010-06-02 07:20:45 UTC (rev 8053)
+++ projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml 2010-06-02 07:26:44 UTC (rev 8054)
@@ -139,7 +139,7 @@
</mbean>
]]></programlisting>
</section>
- <section id="conf.serverpeer.attributes">
+ <section id="sect-ServerPeer_Attributes">
<title>ServerPeer attributes</title>
<para>
This section discusses the <literal>ServerPeer</literal> managed bean attributes.
@@ -241,10 +241,10 @@
</listitem>
</varlistentry>
<varlistentry>
- <term>ClusterPullConnectionFactory</term>
+ <term>ClusterPullConnectionFactoryName</term>
<listitem>
<para>
- The connection factory used to pull, or suck, messages between queues. You can omit this attribute to disable message sucking while retaining failover.</para>
+ The connection factory used to pull, or suck, messages between queues. You can omit this attribute to disable message sucking while retaining failover. Refer to </para>
</listitem>
</varlistentry>
<varlistentry>
@@ -364,7 +364,7 @@
</listitem>
</varlistentry>
</variablelist>
- <section id="conf.serverpeer.operations">
+ <section id="sect-Managed_Beans_In_The_ServerPeer">
<title>Managed Beans in the ServerPeer</title>
<para>The following managed beans are available for the ServerPeer managed bean:</para>
<variablelist>
@@ -472,7 +472,7 @@
</variablelist>
</section>
</section>
- <section id="conf.changingds">
+ <section id="sect-Changing_The_Database">
<title>Changing the Database</title>
<para>
The Persistence Manager, Post Office and JMS User Manager all interact with persistent storage. The Persistence Manager handles message-related persistence. The Post Office handles binding related persistence. The JMS User Manager handles user-related persistence. All configuration for these managed beans is handled in the <filename><your database type>-persistence-service.xml</filename> file.
@@ -695,7 +695,7 @@
</mbean>
]]></programlisting>
- <section id="conf.postoffice.attributes">
+ <section id="sect-Post_Office_Attributes">
<title>Post Office Attributes</title>
<para>The following attributes are available to configure the Messaging Post Office:</para>
<variablelist>
@@ -819,7 +819,7 @@
</variablelist>
</section>
</section>
- <section id="conf.persistencemanager">
+ <section id="sect-Configuring_The_Persistence_Manager">
<title>Configuring the Persistence Manager</title>
<para>The Persistence Manager manages all message-related persistence. JBoss Messaging ships with a JDBC Persistence Manager, which handles message data persistence in a relational database accessed via JDBC. The Persistence Manager can be plugged into the Messaging server, which allows additional implementations to persist message data in non-relational stores, and file stores.
</para>
@@ -1851,7 +1851,7 @@
</mbean>
]]></programlisting>
</example>
- <section id="conf.connectionfactory.attributes">
+ <section id="sect-ConnectionFactory_Managed_Bean_Attributes">
<title>ConnectionFactory Managed Bean Attributes</title>
<variablelist>
<varlistentry>
More information about the jboss-cvs-commits
mailing list