conflict between stomp headers and jms property names?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

conflict between stomp headers and jms property names?

Mike Kelley
I'm investigating different messaging platforms for my company. Most of our code base is currently in Java, C++, Ruby, and PHP. We need to exchange text messages between code in the 1st 3 and preferably all 4 languages.  To date we've been using ActiveMQ, ActiveMQ-CPP, StompConnect and stomp-1.0.6. I've been looking harder at JBoss Messaging but found it rejects messages from Ruby clients. Ruby-generated messages all include a "content-type" header, which JBoss rejects since "content-type" isn't a valid Java identifier.

Something has to give here, but I'm not sure what or where :)

The simplest and most expedient solution is for me to modify our Ruby stomp library to generate/parse different names that JBoss (and ActiveMQ) will accept.

However I thought perhaps it was worth posing to the group: is it worth changing the stomp protocol specification (say, to use underscores instead of dashes)?  Although the JMS spec doesn't specifically preclude properties such as 'content-type', I think JBoss is doing a reasonable thing by disallowing them. If the point of having properties is to filter/route based on them, and the selection syntax dictates the character set for valid identifiers, it doesn't make much sense to allow '-' in property names.

Thoughts?

Mike

Reply | Threaded
Open this post in threaded view
|

Re: conflict between stomp headers and jms property names?

caboteria
I've just been bitten by the same bug while trying to send messages from Ruby to a JMS implementation via the StompConnect gateway.  I believe that the Ruby client shouldn't add any headers that aren't required by the protocol, and the AFAICT protocol doesn't require content-type.

There's a patch on RubyForge that allows ruby clients to tell the driver to not send the content-type header, which would work OK for me:
http://rubyforge.org/tracker/index.php?func=detail&aid=16967&group_id=1010&atid=3983

What do the Ruby client developers think of this patch?

Thanks,
Toby