It's a fair point, and I've used both approaches in the past, but when you're using the Spring framework for almost everything else then it's natural to also use its messaging abstractions, and in most cases it does simplify JMS usage and configuration. While looking into the persistence problem I found numerous posting about JMSTemplate's performance failings, but as detailed in chriswongdevblog.blogspot.co.uk/2013/01/jmstemplate-is-not-evil.html the problem often turns out to be because Spring applies defaults which aren't optimal in many applications, and in practice it's a fairly thin shim over the JMS API. I suppose there are similar arguments for and against most API abstractions, for example Spring data vs Hibernate (or other ORM) vs JDBC vs ODBC vs specific database APIs. If performance or fine grained control is key then diving in at a lower level makes sense, but often the higher level abstraction provides convenience at a small expense.
-- View this message in context: http://activemq.2283324.n4.nabble.com/Non-persistent-deliverymode-not-effect-tp4680457p4715000.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
