Asynchronous Messaging Made Easy With Spring JMS
Subject:   Conclusion is contradictory
Date:   2006-02-27 10:38:51
From:   sreich
Listings 2 through 8 contain XML configuration for Spring, their total length alone exceeds the length of the code in Listing 9, the traditional JMS use case.
By using Spring, you need to add another framework to your application, learn the API, maintain it, add new configuration files to your projects that must be synced with deployment and container descriptors, but which are not accessible by J2EE tooling, just to save a dozen lines of boilerplate code?
Please help me understand your argumentation that your solution is easier and more maintainable.
Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • Conclusion is contradictory
    2006-03-03 20:16:16  bpoitras [View]

    There is no reason to have to use XML for such a simple example. You can construct a JmsTemplate from a ConnectionFactory and use that simply your JMS code without any XML. For some reason any simple example using Spring seems to require XML in these articles. And as a result gives people a bad impression of Spring.
  • Conclusion is contradictory
    2006-02-28 02:00:16  gepo [View]

    I agree. Introducing another framework only due to JMS boilerplate code (which you easily hide with a fascade) is just not worth it.
    • Conclusion is contradictory
      2006-02-28 07:45:32  srinip [View]

      The proposed design may not be the right solution for all the projects out there. But in our project, we had several JMS destinations that needed to be managed in dev, staging, and prod environments and using Spring's JMS template approach worked great for us. We found that using Spring made the design and development very modular and it was easy to create isolated tests. I think Spring is more than just another framework. We are using it in all layers our J2EE application (MVC, JDBC, JNDI, JMS etc) and it works perfectly with the TDD concept.