[hornetq-commits] JBoss hornetq SVN: r8772 - in trunk: examples/jms/pre-acknowledge/src/org/hornetq/jms/example and 8 other directories.

do-not-reply at jboss.org do-not-reply at jboss.org
Thu Jan 7 12:32:08 EST 2010


Author: timfox
Date: 2010-01-07 12:32:07 -0500 (Thu, 07 Jan 2010)
New Revision: 8772

Added:
   trunk/src/main/org/hornetq/api/jms/HornetQJMSConstants.java
Removed:
   trunk/src/main/org/hornetq/api/jms/HornetQMessageConstants.java
Modified:
   trunk/docs/user-manual/en/last-value-queues.xml
   trunk/docs/user-manual/en/message-grouping.xml
   trunk/docs/user-manual/en/pre-acknowledge.xml
   trunk/docs/user-manual/en/scheduled-messages.xml
   trunk/examples/jms/pre-acknowledge/src/org/hornetq/jms/example/PreacknowledgeExample.java
   trunk/src/main/org/hornetq/api/core/HornetQBuffers.java
   trunk/src/main/org/hornetq/core/transaction/impl/ResourceManagerImpl.java
   trunk/src/main/org/hornetq/jms/bridge/impl/JMSBridgeImpl.java
   trunk/src/main/org/hornetq/jms/client/HornetQConnection.java
   trunk/src/main/org/hornetq/jms/client/HornetQMessage.java
   trunk/src/main/org/hornetq/jms/client/HornetQSession.java
   trunk/tests/src/org/hornetq/tests/integration/jms/bridge/JMSBridgeTest.java
   trunk/tests/src/org/hornetq/tests/integration/jms/client/ReSendLargeMessageTest.java
   trunk/tests/src/org/hornetq/tests/integration/jms/consumer/ConsumerTest.java
Log:
more docs edits plus moved pre-ack constant into api

Modified: trunk/docs/user-manual/en/last-value-queues.xml
===================================================================
--- trunk/docs/user-manual/en/last-value-queues.xml	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/docs/user-manual/en/last-value-queues.xml	2010-01-07 17:32:07 UTC (rev 8772)
@@ -1,5 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-
 <!-- ============================================================================= -->
 <!-- Copyright © 2009 Red Hat, Inc. and others.                                    -->
 <!--                                                                               -->
@@ -17,7 +16,6 @@
 <!-- and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent        -->
 <!-- permitted by applicable law.                                                  -->
 <!-- ============================================================================= -->
-
 <chapter id="last-value-queues">
    <title>Last-Value Queues</title>
    <para>Last-Value queues are special queues which discard any messages when a newer message with
@@ -40,8 +38,7 @@
    <section>
       <title>Using Last-Value Property</title>
       <para>The property name used to identify the last value is <literal>"_HQ_LVQ_NAME"</literal>
-         (or the constant <literal>MessageImpl.HDR_LAST_VALUE_NAME</literal> from the Core
-         API).</para>
+         (or the constant <literal>Message.HDR_LAST_VALUE_NAME</literal> from the Core API).</para>
       <para>For example, if two messages with the same value for the Last-Value property are sent to
          a Last-Value queue, only the latest message will be kept in the queue:</para>
       <programlisting>
@@ -67,7 +64,7 @@
    </section>
    <section>
       <title>Example</title>
-      <para>See <xref linkend="examples.last-value-queue" /> for an example which
-         shows how last value queues are configured and used with JMS.</para>
+      <para>See <xref linkend="examples.last-value-queue"/> for an example which shows how last
+         value queues are configured and used with JMS.</para>
    </section>
 </chapter>

Modified: trunk/docs/user-manual/en/message-grouping.xml
===================================================================
--- trunk/docs/user-manual/en/message-grouping.xml	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/docs/user-manual/en/message-grouping.xml	2010-01-07 17:32:07 UTC (rev 8772)
@@ -18,7 +18,7 @@
 <!-- ============================================================================= -->
 <chapter id="message-grouping">
    <title>Message Grouping</title>
-   <para>Message groups are sets of messages that has the following characteristics:</para>
+   <para>Message groups are sets of messages that have the following characteristics:</para>
    <itemizedlist>
       <listitem>
          <para>Messages in a message group share the same group id, i.e. they have same group
@@ -32,6 +32,14 @@
             messages with the same group id.</para>
       </listitem>
    </itemizedlist>
+   <para>Message groups are useful when you want all messages for a certain value of the property to
+      be processed serially by the same consumer.</para>
+   <para>An example might be orders for a certain stock. You may want orders for any particular
+      stock to be processed serially by the same consumer. To do this you can create a pool of
+      consumers (perhaps one for each stock, but less will work too), then set the stock name as the
+      value of the _HQ_GROUP_ID property.</para>
+   <para>This will ensure that all messages for a particular stock will always be processed by the
+      same consumer.</para>
    <section>
       <title>Using Core API</title>
       <para>The property name used to identify the message group is <literal
@@ -67,11 +75,12 @@
       &lt;/entries>
       &lt;autogroup>true&lt;/autogroup>
 &lt;/connection-factory></programlisting>
-      <para>Alternatively you can set the group id via the connection factory. All messages sent with producers created
-         via this connection factory will set the <literal>JMSXGroupID</literal> to the specified value on all messages
-         sent. To configure the group id set it on the connection factory in the <literal>hornetq-jms.xml</literal>
-      config file as follows
-      <programlisting>
+      <para>Alternatively you can set the group id via the connection factory. All messages sent
+         with producers created via this connection factory will set the <literal
+            >JMSXGroupID</literal> to the specified value on all messages sent. To configure the
+         group id set it on the connection factory in the <literal>hornetq-jms.xml</literal> config
+         file as follows
+         <programlisting>
          &lt;connection-factory name="ConnectionFactory"&gt;
       &lt;connectors&gt;
          &lt;connector-ref connector-name="netty-connector"/&gt;
@@ -81,8 +90,7 @@
       &lt;/entries>
       &lt;group-id>Group-0&lt;/group-id&gt;
    &lt;/connection-factory&gt;
-      </programlisting>
-      </para>
+      </programlisting></para>
    </section>
    <section>
       <title>Example</title>
@@ -96,16 +104,19 @@
    </section>
    <section>
       <title> Clustered Grouping</title>
-      <para>Using the Grouping function in a cluster is a bit more complex. This is because messages
-         with a particular group id can arrive on any node so each node needs to know about which
-         group id's are bound to which consumer on which node. To solve this there is the notion of
-         a grouping handler. Each node will have its own grouping handler and when a messages is
-         sent with a group id assigned, the handlers will decide between them which route the
-         message should take. There are 2 types of handlers, Local and Remote. Each cluster should
-         assign 1 node to have a local grouping handler and all the other nodes should have remote
-         handlers, Its the local handler that actually makes the decsion as to what route should be
-         used, all the other remote handler converse with this. Here is a sample config for both
-         types of handler, this should be configured in the <emphasis role="italic"
+      <para>Using message groups in a cluster is a bit more complex. This is because messages with a
+         particular group id can arrive on any node so each node needs to know about which group
+         id's are bound to which consumer on which node. The consumer handling messages for a
+         particular group id may be on a different node of the cluster, so each node needs to know
+         this information so it can route the message correctly to the node which has that consumer. </para>
+      <para>To solve this there is the notion of a grouping handler. Each node will have its own
+         grouping handler and when a messages is sent with a group id assigned, the handlers will
+         decide between them which route the message should take.</para>
+      <para>There are 2 types of handlers; Local and Remote. Each cluster should choose 1 node to
+         have a local grouping handler and all the other nodes should have remote handlers- it's the
+         local handler that actually makes the decsion as to what route should be used, all the
+         other remote handlers converse with this. Here is a sample config for both types of
+         handler, this should be configured in the <emphasis role="italic"
             >hornetq-configuration.xml</emphasis>
          file.<programlisting>   &lt;grouping-handler name="my-grouping-handler">
       &lt;type>LOCAL&lt;/type>
@@ -118,7 +129,7 @@
       &lt;address>jms&lt;/address>
       &lt;timeout>5000&lt;/timeout>
    &lt;/grouping-handler></programlisting></para>
-      <para>The <emphasis role="italic">address</emphasis> attribute referes to a cluster connection
+      <para>The <emphasis role="italic">address</emphasis> attribute refers to a cluster connection
          and the address it uses, refer to the clustering section on how to configure clusters. The
             <emphasis role="italic">timeout</emphasis> attribute referes to how long to wait for a
          decision to be made, an exception will be thrown during the send if this timeout is
@@ -128,9 +139,9 @@
          routing conditions, i.e. round robin available queues, use a local queue first and choose a
          queue that has a consumer. If the proposal is excepted by the grouping handlers the node
          will route messages to this queue from that point on, if rejected an alternative route will
-         be offered and the node will again route to that queue indefinately. All other nodes will
+         be offered and the node will again route to that queue indefinitely. All other nodes will
          also route to the queue chosen at proposal time. Once the message arrives at the queue then
-         normal single server message group semantics take over and the message ispinned to a
+         normal single server message group semantics take over and the message is pinned to a
          consumer on that queue.</para>
       <para>You may have noticed that there is a single point of failure with the single local
          handler. If this node crashes then no decisions will be able to be made. Any messages sent
@@ -140,24 +151,30 @@
       <para/>
       <section>
          <title>Clustered Grouping Best Practices</title>
-         <para>Some best practices should be followed when using clustered grouping, these
-               are<orderedlist><listitem><para>Make sure your consumers are distributed evenly
-                     across the different nodes if possible. This is only an issue if you are
-                     creating and closing consumers regularly. Since messages are always routed to
-                     the same queue once pinned, removing a consumer from this queue may leave it
-                     with no consumers meaning the queue will just keep receiving the messages.
-                     Avoid closing consumers or make sure that you always have plenty of consumers,
-                     i.e., if you have 3 nodes have 3
-                     consumers.</para></listitem><listitem><para>Use durable queues if possible. If
-                     queues are removed once a group is bound to it, then it is possible that other
-                     nodes may still try to route messages to it. This can be avoided by making sure
-                     that the queue is deleted by the session that is sending the messages. This
-                     means that when the next message is sent it is sent to the node where the queue
-                     was deleted meaning a new proposal can succesfully take place. Alternatively
-                     you could just start using a different group
-                     id.</para></listitem><listitem><para>Always make sure that the node that has
-                     the Local Grouping Handler is replicated. These means that on failover grouping
-                     will still occur.</para></listitem></orderedlist></para>
+         <para>Some best practices should be followed when using clustered grouping:<orderedlist>
+               <listitem>
+                  <para>Make sure your consumers are distributed evenly across the different nodes
+                     if possible. This is only an issue if you are creating and closing consumers
+                     regularly. Since messages are always routed to the same queue once pinned,
+                     removing a consumer from this queue may leave it with no consumers meaning the
+                     queue will just keep receiving the messages. Avoid closing consumers or make
+                     sure that you always have plenty of consumers, i.e., if you have 3 nodes have 3
+                     consumers.</para>
+               </listitem>
+               <listitem>
+                  <para>Use durable queues if possible. If queues are removed once a group is bound
+                     to it, then it is possible that other nodes may still try to route messages to
+                     it. This can be avoided by making sure that the queue is deleted by the session
+                     that is sending the messages. This means that when the next message is sent it
+                     is sent to the node where the queue was deleted meaning a new proposal can
+                     succesfully take place. Alternatively you could just start using a different
+                     group id.</para>
+               </listitem>
+               <listitem>
+                  <para>Always make sure that the node that has the Local Grouping Handler is
+                     replicated. These means that on failover grouping will still occur.</para>
+               </listitem>
+            </orderedlist></para>
       </section>
       <section>
          <title>Clustered Grouping Example</title>

Modified: trunk/docs/user-manual/en/pre-acknowledge.xml
===================================================================
--- trunk/docs/user-manual/en/pre-acknowledge.xml	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/docs/user-manual/en/pre-acknowledge.xml	2010-01-07 17:32:07 UTC (rev 8772)
@@ -30,16 +30,11 @@
          <para><literal>DUPS_OK_ACKNOWLEDGE</literal></para>
       </listitem>
    </itemizedlist>
-   <para>The acknowledgement modes all involve sending acknowledgements from the client to the
-      server. However, in the case where you can afford to lose messages in event of failure, it
-      would make sense to acknowledge the message on the server <emphasis>before</emphasis>
-      delivering it to the client.</para>
-   <note>
-      <para>Please note, that if you use pre-acknowledge mode, then you will lose transactional
-         semantics for messages being consumed, since clearly they are being acknowledged first on
-         the server, not when you commit the transaction. This may be stating the obvious but we
-         like to be clear on these things to avoid confusion!</para>
-   </note>
+   <para>However there is another case which is not supported by JMS: In some cases you can afford
+      to lose messages in event of failure, so it would make sense to acknowledge the message on the
+      server <emphasis>before</emphasis> delivering it to the client.</para>
+   <para>This extra mode is supported by HornetQ and will call it
+         <emphasis>pre-acknowledge</emphasis> mode.</para>
    <para>The disadvantage of acknowledging on the server before delivery is that the message will be
       lost if the system crashes <emphasis>after</emphasis> acknowledging the message on the server
       but <emphasis>before</emphasis> it is delivered to the client. In that case, the message is
@@ -49,6 +44,12 @@
    <para>An example of a use case for pre-acknowledgement is for stock price update messages. With
       these messages it might be reasonable to lose a message in event of crash, since the next
       price update message will arrive soon, overriding the previous price. </para>
+   <note>
+      <para>Please note, that if you use pre-acknowledge mode, then you will lose transactional
+         semantics for messages being consumed, since clearly they are being acknowledged first on
+         the server, not when you commit the transaction. This may be stating the obvious but we
+         like to be clear on these things to avoid confusion!</para>
+   </note>
    <section id="pre-acknowledge.configure">
       <title>Using PRE_ACKNOWLEDGE</title>
       <para>This can be configured in the <literal>hornetq-jms.xml</literal> file on the <literal
@@ -62,8 +63,8 @@
       &lt;/entries>
       &lt;pre-acknowledge>true&lt;/pre-acknowledge>
 &lt;/connection-factory></programlisting>
-      <para>Alternatively use pre-acknowledgement mode using the JMS API, create a JMS Session with
-         the <literal>HornetQSession.PRE_ACKNOWLEDGE</literal> constant.</para>
+      <para>Alternatively, to use pre-acknowledgement mode using the JMS API, create a JMS Session
+         with the <literal>HornetQSession.PRE_ACKNOWLEDGE</literal> constant.</para>
       <programlisting>
 // messages will be acknowledge on the server *before* being delivered to the client
 Session session = connection.createSession(false, HornetQSession.PRE_ACKNOWLEDGE);

Modified: trunk/docs/user-manual/en/scheduled-messages.xml
===================================================================
--- trunk/docs/user-manual/en/scheduled-messages.xml	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/docs/user-manual/en/scheduled-messages.xml	2010-01-07 17:32:07 UTC (rev 8772)
@@ -1,5 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-
 <!-- ============================================================================= -->
 <!-- Copyright © 2009 Red Hat, Inc. and others.                                    -->
 <!--                                                                               -->
@@ -17,7 +16,6 @@
 <!-- and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent        -->
 <!-- permitted by applicable law.                                                  -->
 <!-- ============================================================================= -->
-
 <chapter id="scheduled-messages">
    <title>Scheduled Messages</title>
    <para>Scheduled messages differ from normal messages in that they won't be delivered until a
@@ -27,7 +25,7 @@
       <title>Scheduled Delivery Property</title>
       <para>The property name used to identify a scheduled message is <literal
             >"_HQ_SCHED_DELIVERY"</literal> (or the constant <literal
-            >MessageImpl.HDR_SCHEDULED_DELIVERY_TIME</literal>).</para>
+            >Message.HDR_SCHEDULED_DELIVERY_TIME</literal>).</para>
       <para>The specified value must be a <literal>long</literal> corresponding to the time the
          message must be delivered (in milliseconds). An example of sending a scheduled message
          using the JMS API is as follows.</para>
@@ -43,11 +41,12 @@
   // message will not be received immediately but 5 seconds later
   TextMessage messageReceived = (TextMessage) consumer.receive();
       </programlisting>
-      <para>Scheduled messages can also be sent using the core API, by setting the same property on the core message before sending.</para>
+      <para>Scheduled messages can also be sent using the core API, by setting the same property on
+         the core message before sending.</para>
    </section>
    <section>
       <title>Example</title>
-      <para>See <xref linkend="examples.scheduled-message" /> for an example which 
-         shows how scheduled messages can be used with JMS.</para>
+      <para>See <xref linkend="examples.scheduled-message"/> for an example which shows how
+         scheduled messages can be used with JMS.</para>
    </section>
 </chapter>

Modified: trunk/examples/jms/pre-acknowledge/src/org/hornetq/jms/example/PreacknowledgeExample.java
===================================================================
--- trunk/examples/jms/pre-acknowledge/src/org/hornetq/jms/example/PreacknowledgeExample.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/examples/jms/pre-acknowledge/src/org/hornetq/jms/example/PreacknowledgeExample.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -26,9 +26,9 @@
 import javax.naming.InitialContext;
 
 import org.hornetq.api.jms.HornetQJMSClient;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.api.jms.management.JMSManagementHelper;
 import org.hornetq.common.example.HornetQExample;
-import org.hornetq.jms.client.HornetQSession;
 
 /**
  * 
@@ -66,7 +66,7 @@
          // Step 3. Create a the JMS objects
          connection = cf.createConnection();
 
-         Session session = connection.createSession(false, HornetQSession.PRE_ACKNOWLEDGE);
+         Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
 
          MessageProducer producer = session.createProducer(queue);
 

Modified: trunk/src/main/org/hornetq/api/core/HornetQBuffers.java
===================================================================
--- trunk/src/main/org/hornetq/api/core/HornetQBuffers.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/api/core/HornetQBuffers.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -53,7 +53,7 @@
    }
 
    /**
-    * Creates a HornetQBuffer wrapping the underlying NIO ByteBuffer
+    * Creates a HornetQBuffer wrapping an underlying NIO ByteBuffer
     * 
     * The position on this buffer won't affect the position on the inner buffer
     * 
@@ -70,7 +70,7 @@
    }
 
    /**
-    * Creates a HornetQBuffer wrapping the underlying byte array
+    * Creates a HornetQBuffer wrapping an underlying byte array
     *
     * @param underlying the underlying byte array
     * @return a HornetQBuffer wrapping the underlying byte array

Copied: trunk/src/main/org/hornetq/api/jms/HornetQJMSConstants.java (from rev 8760, trunk/src/main/org/hornetq/api/jms/HornetQMessageConstants.java)
===================================================================
--- trunk/src/main/org/hornetq/api/jms/HornetQJMSConstants.java	                        (rev 0)
+++ trunk/src/main/org/hornetq/api/jms/HornetQJMSConstants.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2009 Red Hat, Inc.
+ * Red Hat licenses this file to you under the Apache License, version
+ * 2.0 (the "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *    http://www.apache.org/licenses/LICENSE-2.0
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied.  See the License for the specific language governing
+ * permissions and limitations under the License.
+ */
+
+package org.hornetq.api.jms;
+
+/**
+ * Constants for HornetQ for property keys used for HornetQ specific extensions to JMS
+ *
+ * @author Tim Fox
+ *
+ *
+ */
+public class HornetQJMSConstants
+{
+   public static final String JMS_HORNETQ_INPUT_STREAM = "JMS_HQ_InputStream";
+   
+   public static final String JMS_HORNETQ_OUTPUT_STREAM = "JMS_HQ_OutputStream";
+   
+   public static final String JMS_HORNETQ_SAVE_STREAM = "JMS_HQ_SaveStream";
+   
+   public static final String JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST = "HQ_BRIDGE_MSG_ID_LIST";
+
+   public static final int PRE_ACKNOWLEDGE = 100;
+}

Deleted: trunk/src/main/org/hornetq/api/jms/HornetQMessageConstants.java
===================================================================
--- trunk/src/main/org/hornetq/api/jms/HornetQMessageConstants.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/api/jms/HornetQMessageConstants.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -1,32 +0,0 @@
-/*
- * Copyright 2009 Red Hat, Inc.
- * Red Hat licenses this file to you under the Apache License, version
- * 2.0 (the "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *    http://www.apache.org/licenses/LICENSE-2.0
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- * implied.  See the License for the specific language governing
- * permissions and limitations under the License.
- */
-
-package org.hornetq.api.jms;
-
-/**
- * Constants for HornetQ for property keys used for HornetQ specific extensions to JMS
- *
- * @author Tim Fox
- *
- *
- */
-public class HornetQMessageConstants
-{
-   public static final String JMS_HORNETQ_INPUT_STREAM = "JMS_HQ_InputStream";
-   
-   public static final String JMS_HORNETQ_OUTPUT_STREAM = "JMS_HQ_OutputStream";
-   
-   public static final String JMS_HORNETQ_SAVE_STREAM = "JMS_HQ_SaveStream";
-   
-   public static final String JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST = "HQ_BRIDGE_MSG_ID_LIST";
-}

Modified: trunk/src/main/org/hornetq/core/transaction/impl/ResourceManagerImpl.java
===================================================================
--- trunk/src/main/org/hornetq/core/transaction/impl/ResourceManagerImpl.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/core/transaction/impl/ResourceManagerImpl.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -212,7 +212,7 @@
       return xids;
    }
 
-   class TxTimeoutHandler implements Runnable
+   private class TxTimeoutHandler implements Runnable
    {
       private boolean closed = false;
 

Modified: trunk/src/main/org/hornetq/jms/bridge/impl/JMSBridgeImpl.java
===================================================================
--- trunk/src/main/org/hornetq/jms/bridge/impl/JMSBridgeImpl.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/jms/bridge/impl/JMSBridgeImpl.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -41,7 +41,7 @@
 import javax.transaction.xa.XAResource;
 
 import org.hornetq.api.core.client.ClientSession;
-import org.hornetq.api.jms.HornetQMessageConstants;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.core.logging.Logger;
 import org.hornetq.core.server.HornetQComponent;
 import org.hornetq.jms.bridge.ConnectionFactoryFactory;
@@ -1639,7 +1639,7 @@
 
       String val = null;
 
-      val = msg.getStringProperty(HornetQMessageConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
+      val = msg.getStringProperty(HornetQJMSConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
 
       if (val == null)
       {
@@ -1654,7 +1654,7 @@
          val = sb.toString();
       }
 
-      msg.setStringProperty(HornetQMessageConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST, val);
+      msg.setStringProperty(HornetQJMSConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST, val);
    }
 
    /*

Modified: trunk/src/main/org/hornetq/jms/client/HornetQConnection.java
===================================================================
--- trunk/src/main/org/hornetq/jms/client/HornetQConnection.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/jms/client/HornetQConnection.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -44,6 +44,7 @@
 import org.hornetq.api.core.client.ClientSession;
 import org.hornetq.api.core.client.ClientSessionFactory;
 import org.hornetq.api.core.client.SessionFailureListener;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.core.logging.Logger;
 import org.hornetq.core.version.Version;
 import org.hornetq.utils.UUIDGenerator;
@@ -508,7 +509,7 @@
                                                    sessionFactory.isPreAcknowledge(),
                                                    transactionBatchSize);
          }
-         else if (acknowledgeMode == HornetQSession.PRE_ACKNOWLEDGE)
+         else if (acknowledgeMode == HornetQJMSConstants.PRE_ACKNOWLEDGE)
          {
             session = sessionFactory.createSession(username, password, isXA, true, false, true, transactionBatchSize);
          }

Modified: trunk/src/main/org/hornetq/jms/client/HornetQMessage.java
===================================================================
--- trunk/src/main/org/hornetq/jms/client/HornetQMessage.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/jms/client/HornetQMessage.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -39,7 +39,7 @@
 import org.hornetq.api.core.SimpleString;
 import org.hornetq.api.core.client.ClientMessage;
 import org.hornetq.api.core.client.ClientSession;
-import org.hornetq.api.jms.HornetQMessageConstants;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.core.client.impl.ClientMessageImpl;
 import org.hornetq.core.logging.Logger;
 
@@ -788,13 +788,13 @@
 
    public void setObjectProperty(final String name, final Object value) throws JMSException
    {
-      if (HornetQMessageConstants.JMS_HORNETQ_OUTPUT_STREAM.equals(name))
+      if (HornetQJMSConstants.JMS_HORNETQ_OUTPUT_STREAM.equals(name))
       {
          setOutputStream((OutputStream)value);
 
          return;
       }
-      else if (HornetQMessageConstants.JMS_HORNETQ_SAVE_STREAM.equals(name))
+      else if (HornetQJMSConstants.JMS_HORNETQ_SAVE_STREAM.equals(name))
       {
          saveToOutputStream((OutputStream)value);
 
@@ -809,7 +809,7 @@
          return;
       }
 
-      if (HornetQMessageConstants.JMS_HORNETQ_INPUT_STREAM.equals(name))
+      if (HornetQJMSConstants.JMS_HORNETQ_INPUT_STREAM.equals(name))
       {
          setInputStream((InputStream)value);
 
@@ -977,11 +977,11 @@
    {
       if (propertiesReadOnly)
       {
-         if (name.equals(HornetQMessageConstants.JMS_HORNETQ_INPUT_STREAM))
+         if (name.equals(HornetQJMSConstants.JMS_HORNETQ_INPUT_STREAM))
          {
-            throw new MessageNotWriteableException("You cannot set the Input Stream on received messages. Did you mean " + HornetQMessageConstants.JMS_HORNETQ_OUTPUT_STREAM +
+            throw new MessageNotWriteableException("You cannot set the Input Stream on received messages. Did you mean " + HornetQJMSConstants.JMS_HORNETQ_OUTPUT_STREAM +
                                                    " or " +
-                                                   HornetQMessageConstants.JMS_HORNETQ_SAVE_STREAM +
+                                                   HornetQJMSConstants.JMS_HORNETQ_SAVE_STREAM +
                                                    "?");
          }
          else

Modified: trunk/src/main/org/hornetq/jms/client/HornetQSession.java
===================================================================
--- trunk/src/main/org/hornetq/jms/client/HornetQSession.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/src/main/org/hornetq/jms/client/HornetQSession.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -86,8 +86,6 @@
 
    public static final int TYPE_TOPIC_SESSION = 2;
 
-   public static final int PRE_ACKNOWLEDGE = 100;
-
    private static SimpleString REJECTING_FILTER = new SimpleString("_HQX=-1");
 
    // Static --------------------------------------------------------

Modified: trunk/tests/src/org/hornetq/tests/integration/jms/bridge/JMSBridgeTest.java
===================================================================
--- trunk/tests/src/org/hornetq/tests/integration/jms/bridge/JMSBridgeTest.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/tests/src/org/hornetq/tests/integration/jms/bridge/JMSBridgeTest.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -31,7 +31,7 @@
 
 import junit.framework.Assert;
 
-import org.hornetq.api.jms.HornetQMessageConstants;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.core.logging.Logger;
 import org.hornetq.jms.bridge.QualityOfServiceMode;
 import org.hornetq.jms.bridge.impl.JMSBridgeImpl;
@@ -959,7 +959,7 @@
 
             if (on)
             {
-               String header = tm.getStringProperty(HornetQMessageConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
+               String header = tm.getStringProperty(HornetQJMSConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
 
                Assert.assertNotNull(header);
 
@@ -1002,7 +1002,7 @@
 
                Assert.assertEquals("mygroup543", tm.getStringProperty("JMSXGroupID"));
 
-               String header = tm.getStringProperty(HornetQMessageConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
+               String header = tm.getStringProperty(HornetQJMSConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
 
                Assert.assertNotNull(header);
 
@@ -1299,7 +1299,7 @@
             Assert.assertTrue(tm.getBooleanProperty("cheese"));
             Assert.assertEquals(23, tm.getIntProperty("Sausages"));
 
-            String header = tm.getStringProperty(HornetQMessageConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
+            String header = tm.getStringProperty(HornetQJMSConstants.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST);
 
             Assert.assertNull(header);
          }

Modified: trunk/tests/src/org/hornetq/tests/integration/jms/client/ReSendLargeMessageTest.java
===================================================================
--- trunk/tests/src/org/hornetq/tests/integration/jms/client/ReSendLargeMessageTest.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/tests/src/org/hornetq/tests/integration/jms/client/ReSendLargeMessageTest.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -33,7 +33,7 @@
 import org.hornetq.api.core.Pair;
 import org.hornetq.api.core.TransportConfiguration;
 import org.hornetq.api.core.client.HornetQClient;
-import org.hornetq.api.jms.HornetQMessageConstants;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.tests.util.JMSTestBase;
 import org.hornetq.tests.util.UnitTestCase;
 
@@ -72,7 +72,7 @@
          for (int i = 0; i < 10; i++)
          {
             BytesMessage bm = sess.createBytesMessage();
-            bm.setObjectProperty(HornetQMessageConstants.JMS_HORNETQ_INPUT_STREAM,
+            bm.setObjectProperty(HornetQJMSConstants.JMS_HORNETQ_INPUT_STREAM,
                                  UnitTestCase.createFakeLargeStream(2 * HornetQClient.DEFAULT_MIN_LARGE_MESSAGE_SIZE));
             msgs.add(bm);
 

Modified: trunk/tests/src/org/hornetq/tests/integration/jms/consumer/ConsumerTest.java
===================================================================
--- trunk/tests/src/org/hornetq/tests/integration/jms/consumer/ConsumerTest.java	2010-01-07 17:07:05 UTC (rev 8771)
+++ trunk/tests/src/org/hornetq/tests/integration/jms/consumer/ConsumerTest.java	2010-01-07 17:32:07 UTC (rev 8772)
@@ -26,11 +26,11 @@
 import org.hornetq.api.core.SimpleString;
 import org.hornetq.api.core.TransportConfiguration;
 import org.hornetq.api.jms.HornetQJMSClient;
+import org.hornetq.api.jms.HornetQJMSConstants;
 import org.hornetq.core.logging.Logger;
 import org.hornetq.core.server.Queue;
 import org.hornetq.jms.client.HornetQConnectionFactory;
 import org.hornetq.jms.client.HornetQQueue;
-import org.hornetq.jms.client.HornetQSession;
 import org.hornetq.tests.util.JMSTestBase;
 
 /**
@@ -64,7 +64,7 @@
    public void testPreCommitAcks() throws Exception
    {
       Connection conn = cf.createConnection();
-      Session session = conn.createSession(false, HornetQSession.PRE_ACKNOWLEDGE);
+      Session session = conn.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
       jBossQueue = (HornetQQueue) HornetQJMSClient.createQueue(ConsumerTest.Q_NAME);
       MessageProducer producer = session.createProducer(jBossQueue);
       MessageConsumer consumer = session.createConsumer(jBossQueue);
@@ -121,7 +121,7 @@
       ConsumerTest.log.info("starting test");
 
       Connection conn = cf.createConnection();
-      Session session = conn.createSession(false, HornetQSession.PRE_ACKNOWLEDGE);
+      Session session = conn.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
       jBossQueue = (HornetQQueue) HornetQJMSClient.createQueue(ConsumerTest.Q_NAME);
       MessageProducer producer = session.createProducer(jBossQueue);
       MessageConsumer consumer = session.createConsumer(jBossQueue);



More information about the hornetq-commits mailing list