On Sat, Aug 22, 2009 at 10:28 AM, gonzus<gonzalo.dieth...@diethelm.org> wrote: > > 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?
Yes, that is correct and a pretty huge benefit given the incredible amount of goodies in the Spring Framework. > 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? Yes, that is also correct. The Spring Framework does not contain a JMS provider. Instead it provides JMS client APIs that work with any JMS provider. > 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)? I'm guessing that you're referring to the following page: http://activemq.apache.org/jmstemplate-gotchas.html This page is mainly referring to the type of connection factory you're using with the Spring JmsTemplate. Because connection factories are specific to the JMS provider, and because not all connection factories pool sessions, it's important to be aware of the fact that use of a pooling connection factory is more or less a requirement when using the Spring JmsTemplate. The Spring JMS APIs do provide an efficient connection factory named the CachingConnectionFactory (http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/connection/CachingConnectionFactory.html). This class creates one connection and uses it to create many sessions, a model that works very well with JMS providers. This connection factory will work with all JMS providers because it wraps the JMS provider-specific connection factory. Bruce -- perl -e 'print unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
