I'm using Bitronix Transaction Manager for all TX related operations. It
provides me with a class that will manage the JmsConnectionFactory by
wrapping it in a ConnectionPool. All access to the ConnectionFactory is
managed by this class.
<bean id="jmsConnectionFactoryBean"
class="bitronix.tm.resource.jms.ConnectionFactoryBean">
<property name="className"
value="org.apache.activemq.ActiveMQXAConnectionFactory" />
<property name="uniqueName" value="ActiveMQXAConnectionFactory" />
<property name="poolSize" value="10" />
<property name="driverProperties">
<props>
<prop key="brokerURL">${jms.connection.factory.brokerUrl}</prop>
</props>
</property>
</bean>
James.Strachan wrote:
>
> On 3/9/07, cmathrusse <[EMAIL PROTECTED]> wrote:
>>
>> Yes, the change to port 2100 was intentional. The activemq.xml file on
>> the
>> server was updated to this value. If it hadn't been I would not have been
>> able to connect to it.
>>
>> My server application is using the JmsTemplate but that is not the issue
>> as
>> I am using ConnectionPooling.
>
> How just out of interest?
>
>
>> I've managed to get things to work a bit. I modified both my simple
>> client
>> and the client application by including a jndi.properties file in their
>> classpath. The simple java client was able to connect successfully and
>> perform a lookup of the queues, which I had predefined on the server.
>
> FWIW you don't need to predefine queues on the server...
> http://activemq.apache.org/how-do-i-create-new-destinations.html
>
>
>> I was
>> able to find, using the simple java client, the queue with a
>> ctx.lookup(queueName);, and send a message successfully. The
>> consumer/server
>> application received this message successfully.
>
> Great
>
>
>> Next I tried from the 3rd
>> party client application, but the lookup still failed.
>
> Was the 3rd party client using the same jndi.properties and expecting
> things in the same places?
>
>
>> So I modified the
>> lookup to use the dynamic queue syntax,
>> ctx.lookup("dynamicQueues/order.request.queue");. This worked and the
>> application was able to send successfully.
>
> Great!
>
>> Surprisingly the consumer received the message and was able to process
>> it.
>
> :)
>
>
>> The only modification I made on the consumer side was that I changed the
>> queue name that it was listening on. Previously I had it listening to
>> "dynamicQueues/order.request.queue" and I changed it to
>> "order.request.queue". For some reason removing the dynamicQueues syntax
>> seemed to correct the problem.
>>
>> I wish I had a good explanation for this.
>
> So I think JNDI has caused most of the grief in this - for most of the
> time its kinda an unnecessary level of indirection that just causes
> work (setting up the damn jndi contexts) and causes confusion.
>
> Really in JMS destinations are just URIs - you don't need to use JNDI
> for them. Imagine if the Servlet spec said you had to register every
> URI you were gonna use in a servlet engine in JNDI!
>
> To actually answer your final question - you're confusing the JNDI
> lookup name with the JMS destination name. The JNDI name
>
> "dynamicQueues/order.request.queue"
>
> means use queue "order.request.queue"
>
> Its the same as doing
>
> new ActiveMQQueue("order.request.queue")
>
> which is the easiest.
>
> Or via jms
>
> session.createQueue("order.request.queue" )
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context:
http://www.nabble.com/Message-is-not-delivered-and-disappears-tf3371445s2354.html#a9399800
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
