activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mittler, Nathan" <>
Subject RE: STOMP and JMSType
Date Wed, 14 Jun 2006 11:54:58 GMT
For map messages, on the c++ side of things we would essentially have to
write a schema file for the layout of a map message.  The c++ stomp
client would have to be coded against that schema to properly parse the
message.  Unfortunately, we don't have the luxury of using a tool like
XStream that uses reflection ... makes you wonder why people still code
in c++! =)

I'm thinking it would be difficult to figure out a way to implement
object messages on the C++ side, since it would have to have a static
set of schemas to look against.  I guess we could break down Objects
into XML at the broker, we could send the XML to the c++ stomp client
and it could just pass the XML up to the application-layer as a text
message.  The user would have to be responsible for parsing it into an
object.  When they send the message, they could just specify the
XmlToObjectMessage transformer so the broker knows what to do.

Another (and much uglier) option would be to create some sort of
ActiveMQ Object class that can be populated from an ObjectMessage XML
file.  It would have attributes and sub-structures that mirror the XML -
essentially a DOM tree.  This would be pretty bizarre and would tie the
client into a slow method of parsing the XML.


-----Original Message-----
From: James Strachan [] 
Sent: Wednesday, June 14, 2006 7:20 AM
Subject: Re: STOMP and JMSType

On 6/14/06, Nathan Mittler <> wrote:
> On 6/14/06, James Strachan <> wrote:
> >
> > On 6/13/06, Nathan Mittler <> wrote:
> > > So it sounds like we're all in agreement on the content-type
> > header.  For
> > > text, it would be something like "text"
> >
> > There could be a few values of Content-type which map to text
> > (text/xml, application/soap, application/xml etc).
> >
> > Incidentally the default implementation for sending an ObjectMessage
> > MapMessage to a Stomp client could be to use XStream to turn it into
> > XML and mark it as text/xml. Otherwise its gonna be extremely hard
> > a typical Stomp client to read the message.
> So if we were to have text, object, and map messages all with a
> of "text/xml", then we would need another parameter, such as the
> "amq-msg-type" that tells a JMS-like stomp client (such as CMS) which
it is,
> so it can create the appropriate object to return to the user.  I
could key
> off the amq-msg-type and then check the content-type to make sure it's
> as expected.  Then I could parse the XML to create the MapMessage, for
> example.  Not quite sure how ObjectMessages would work, however.

Good point. I was kinda thinking of JMS -> Stomp so that any Stomp
client could actually read all the possible the messages from JMS.
But there's also the requirement that a Stomp client be capable of
sending a Map/Object message to an existing JMS consumer.

To send an ObjectMessages into ActiveMQ we could just parse the XML
from Stomp using XStream and set the body of the ObjectMessages to be
whatever XStream parses.



View raw message