2009/3/18 Antsa <a...@teamware.com>: > > > 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. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
