On 6/14/06, Nathan Mittler <[EMAIL PROTECTED]> wrote:
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?
I guess that is the question. For sake of backward compatibility I
would say keep it as is. But we should revisit this once the STOMP
spec has a more specific Appendix on how to do stomp to jms mapping.
--
> Regards,
> Hiram
>
--
Regards,
Hiram
