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. Nate -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 7:20 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On 6/14/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > On 6/14/06, James Strachan <[EMAIL PROTECTED]> wrote: > > > > On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> 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 for > > a typical Stomp client to read the message. > > > So if we were to have text, object, and map messages all with a content-type > 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 XML, > 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. -- James ------- http://radio.weblogs.com/0112098/
