Hello Bruce, thanks for your response.
bsnyder wrote: > > I have always recommended the use of the Spring Framework for building > Java apps. It's diminishes the complexity of the application and provides > many well-tested, widely used convenience classes. In fact, ActiveMQ > itself is built on top of the Spring Framework. > Ok, this is exactly the kind of opinion / information I was looking for. Thanks for sharing it. bsnyder wrote: > > One item I stress to my customers is not to create homegrown JMS clients > unless you have an extremely good reason for doing so. When creating > homegrown JMS clients you need to worry about creating your own > MessageProducers and MessageConsumers, you must manually manage > concurrency, transactionality, and resources. The biggest mistake people > make is underestimating the level of effort and time this involves. The > complexity in creating homegrown JMS clients far outweighs adopting the > tools in the Spring JMS APIs such as the JmsTemplate and the message > listener containers. > Check. I would conclude, then, that when one develops a JMS client with Spring, one can also use all of the other niceties associated with Spring: ease of configuration, POJOs, orthogonal transactions and logging, etc. Is this right? bsnyder wrote: > > In a situation where you might be switching between JMS providers, the > biggest advantage to using the Spring JMS APIs is that you don't need to > rewrite your JMS clients. The Spring JMS APIs will work with any JMS > compliant provider. The work to switch between JMS providers includes > first changing the connection factory that is specific to a JMS provider, > and then testing that the configuration utilized from the Spring JMS APIs > (e.g., caching, concurrent consumers, task executors, etc.) are > appropriate for the new JMS provider. > Excellent news. I found what I must suppose was an old article on Spring JMS that confused me into thinking the people at the Spring project were implementing their own flavor of ActiveMQ (that is, a new, complete JMS provider); your statement confirms that this is not the case, and that Spring JMS is a wrapper around the JMS API, that could be used with any JMS provider. Is this correct? bsnyder wrote: > >> On the minus side, would I be likely to fall into any pitfalls by using >> Spring? > > Not particularly. As a testament to it's extraordinarily widespread > adoption and incredible flexibility, the Spring Framework has been > deployed with all the application servers and web containers in existence > as well as with POJO-based applications, too. I've always been very > surprised how far and wide I've seen the Spring Framework used on my > travels as a consultant over the years. > How about some performance concerns stated in the ActiveMQ web site, where it says that when you use Spring you might be creating and destroying most / all of your JMS objects almost indiscriminately, rather than pooling and reusing them? If this is really a problem with Spring JMS, and ActiveMQ has a solution for it, would this solution work across all JMS providers (should I decide to switch)? Thanks again and best regards. -- View this message in context: http://www.nabble.com/Any-advantage-in-using-Spring--tp25088551p25095336.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
