This content has been marked as final.
Show 4 replies
-
1. Re: JMSTemplate alternatives?
timfox Nov 3, 2009 6:43 PM (in response to jamescarr)Why would you want a replacement?
What's wrong with the JMS API (or the HornetQ core API) ? -
2. Re: JMSTemplate alternatives?
clebert.suconic Nov 3, 2009 9:56 PM (in response to jamescarr)I don't think that's HornetQ's privilege only. Other providers will show issues with the JMSTemplate also. Just google for it and you will find it.
-
3. Re: JMSTemplate alternatives?
jamescarr Nov 4, 2009 12:17 PM (in response to jamescarr)My question might have came off wrong. I don't mean a replacement for HornetQ, I meant a replacement for JMSTemplate. I suppose just plain vanilla JMS might be the answer :)
-
4. Re: JMSTemplate alternatives?
timfox Nov 4, 2009 12:30 PM (in response to jamescarr)"jamescarr" wrote:
My question might have came off wrong. I don't mean a replacement for HornetQ, I meant a replacement for JMSTemplate. I suppose just plain vanilla JMS might be the answer :)
I understood you right the first time :)
I understood you meant a replacement for the JMSTemplate - and my question was - what's wrong with the JMS API?
Personally I don't understand the Spring fixation with flattening APIs - in my view you end up with an abomination which encourages anti-patterns, and leads to a poor understanding of the messaging paradigm.
The JMS API has a separation between connection, session etc for a reason.
Connections, sessions are supposed to be long live entities, sessions encapsulate a transaction context etc.