activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: ActiveMQ JNDI support only for testing?
Date Wed, 18 Mar 2009 09:39:27 GMT
2009/3/18 Antsa <>:
> huntc wrote:
>> I'm curious as to what is trying to be achieved here. Could you please
>> explain why it is useful to perform a naming/directory lookup for a queue
>> or topic name?
> My use case is probably due to my newbie status with JMS.
> Session.createTopic javadocs imply that normal JMS usage would rarely
> require this and I felt it implied that it was not really the way to do
> things.  I was therefore looking at generic ways to create Destination
> objects in the client side.
> My solution for the moment is to use Spring's JmsTemplate class which takes
> String destinationName and then uses the configured destinationResolver to
> get the object.

Than sounds fine to me.

I think some of the motivation since J2EE came along of putting all
your resources (connections, destinations etc) into JNDI was so that a
single deployment unit can be used in dev, testing, production without
being changed - yet you'll be using different database/broker servers
in each environment. Folks could, if they want, use different
topic/queue names in dev to production.

Though given how easy it is to create topics/queues with ActiveMQ I'd
recommend just using the correct names of queue/topic you want to use
in production everywhere - then just having one or more brokers for
each environment. i.e. the only real thing that changes between
dev/test/production for ActiveMQ is the broker connection URL. This
then avoids having loads of double indirections and things that could
go wrong (e.g. remote JNDI servers - then configuring on both the
client and on the JNDI server the mapping between JNDI names to
topic/queue names - which are super easy to get wrong causing loads of
wasted time head scratching).

In practice I've found putting JMS destinations into a remote JNDI
server to be nothing but loads of hard work for no actual gain.

Using spring's property resolving mechanism seems a reasonable
solution so that this URL (and the database connection URL you'll
probably be using too) can be changed in testing & production.


Open Source Integration

View raw message