activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: STOMP and JMSType
Date Wed, 14 Jun 2006 22:34:43 GMT
On 6/14/06, Nathan Mittler <nathan.mittler@gmail.com> wrote:
> On 6/14/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > On 6/14/06, Nathan Mittler <nathan.mittler@gmail.com> 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

Mime
View raw message