activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Mittler" <nathan.mitt...@gmail.com>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 22:33:30 GMT
>
>
>
> Sure.  that would be handy.  But you could also eventualy support Map
> messages too right?


That's certainly a possibility.  We'd just have to come up with a form for
the body of the stomp frame in that case - shouldn't be terribly difficult.

> With that said, I'm not seeing how I can do that mapping if the
> transformer
> > is provided only in the SUBSCRIBE.  A client could potentially get a
> variety
> > of message types from a single subscription.  I think it would have to
> be
> > part of the MESSAGE frame, rather than the SUBSCRIBE.
> >
>
> Well, when the publisher is a pure jms client, he wont be providing a
> header for the transform type right?  What I was thinking is that when
> the client says SUBSCRIBE with x transform, it basically sets up a
> contract that given all the JMS message types a well defined
> transformation to STOMP frames will be done.  It could be that a
> future transform will take a Map messages and turn it into XML and put
> that in a text stomp frame.  But a different transformation might take
> a Map message and do a binary encoding of the key value pairs.  Either
> way the client will know what to expect because he requested it on the
> SUBSCRIBE.


Ok, I think I'm starting to get it ... finally :).   So it sounds like the
main idea for the transformers is not bytes/text messages, which are
low-level protocol-specific stuff ... rather, it's more like
application-level transforms.  So the application layer might say, I want
this to become SOAP at the broker or something like that.

What I need is just a protocol-specific header (I've been calling it
"amq-msg-type") that tells me how to treat the payload (in raw JMS message
terms).  So I think we're talking about two different issues.  In JIRA issue
739, I was addressing the protocol-level need for a message type. It sounds
like we need another issue to capture the transformation refactoring to
support adapting to other message types.

--
> Regards,
> Hiram
>

Regards,
Nate

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message