On 6/14/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
On 6/14/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > A whiteboard would be really handy ... you guys aren't in NY by any chance, > are you? ;) > DOH I was just there last week (for 3 hours)! Want to visit Tampa Florida?
HA ... give me a call after hurricane season!
So what I've gathered from the previous exchange is that we need to provide > a stomp-to-jms message mapping as Hiram suggested (as a stomp extension for > AMQ) > yep. > Here are what I see as the use cases for my CMS client: > 1) Stomp client sends a CMS::TextMessage, JMS client receives a TextMessage > 2) Stomp client sends a CMS::BytesMessage, JMS client receives a > BytesMessage > 3) JMS client sends a TextMessage, Stomp client receives a CMS::TextMessage > 4) JMS client sends a BytesMessage, Stomp client receives a > CMS::BytesMessage Yep this is clear. > 5) JMS client sends !(text || bytes message) - Stomp client error - > unsupported jms message type. (One way this could be resolved is to have > some sort of transformer at the broker that stuffs Object and Map messages > into a bytes or text message ... perhaps as XML, like James suggested ... > this, however is a different issue altogether) > I would say if your CMS client wants to stay vendor neutral and not use a ActiveMQ transformation, then we can 1) give an error to the client 2) avoid consuming those types of messages by adding a selector predicate on the subscription or 3) silently consume those messages. I'm partial to #2. > So here are the things I need you guys to help me fill in: > So, from you previous email, I'm assuming the following questions is in regards to a standarized and portable STOMP to JMS mapping. Currently I think the way we implemented it (correct me if I'm wrong), is that if a STOMP message has content-length, then it's turned into a BytesMessage. And if it does not then its' turned into a TextMessage. And the reverse would be true when sending down to STOMP client from the broker. Are we talking about improving this so that it's more explicit? > 1) What header should I use to do this mapping? > > 2) What are the standard values for this header and how do I make a > determination when I receive a message in the C++ client of text or bytes? > > 3) Does this header represent some JMS-specific property that would be > settable in the JMS Message interface, such as JMSMessageType? If so, we > should choose another header, because the user could screw up the mapping > done by the CMS library. For example if the client creates a > CMS::TextMessage, this property should be internally set to that of a text > message and the user should not be able to change it. > I guess this all depends on what the issues are with the current way that we do thing. It seems to me that using the content-length header will allow us to switch between bytes and text just fine. But it could be we are talking about making this mapping more explicit than what we are currently doing.
I think I created the issue in response to a user that wanted more explicit control over the message type that is received by JMS. Since STOMP suggests that all messages have content-length, it seems that you might want that on all of your messages, including TextMessages. But your question is valid ... I guess if we just post what happens with AMQ and when (perhaps we already do), then the users can just adjust their clients accordingly. The way we have it now should work for the CMS client - in fact it already does work with the previous version of CMS that is in trunk now. So I vote that we mark this issue as "won't fix" and lay this topic to rest! u with me? --
Regards, Hiram
