当通过STOMP发送时，ActiveMQ在Base64中存储消息？

I'm using the ruby stomp gem to send messages to ActiveMQ. The data is being stored in Base64 encoded form, rather than as text, which is messing with my ability to use XPath selectors!

我正在使用ruby stomp gem向ActiveMQ发送消息。数据以Base64编码形式存储,而不是文本,这使我无法使用XPath选择器!

I've confirmed that using the 'send' functionality within jetty I can send non-Base64 encoded text to the same queue.

我已经确认使用jetty中的'send'功能,我可以将非Base64编码的文本发送到同一个队列。

Any suggestions as to how to stop this from happening?

有关如何阻止这种情况发生的任何建议?

My test code:

我的测试代码:

require 'stomp'

stomp = { 
    :hosts => [{:host => 'localhost', :port => 61613}]
}

client = Stomp::Client.new(stomp)

queue = "/queue/test"
xml = "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<test>xml</test>"

client.publish(queue,xml,{
    :'content-type' => 'application/xml',
    :persistent     => true
})

I can then visit the ActiveMQ demos to see what's actually being stored:

然后我可以访问ActiveMQ演示以查看实际存储的内容:

 http://127.0.0.1:8161/demo/queueBrowse/test?view=xml

Output:

<messages queue="queue://test">
    <!-- snip -->
        <content>
            <data>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8+Cjx0ZXN0PnhtbDwvdGVzdD4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA=</data>
            <offset>0</offset>
            <length>56</length>
        </content>
    <!-- snip -->
</messages>

1 个解决方案

#1

I've solved my own issue - here's a breakdown of why it was occurring.

我已经解决了我自己的问题 - 这里是它发生原因的细分。

ActiveMQ assumes that any incoming STOMP message with a content-length header is a ByteMessage and any without that header is a TextMessage (reference material).

ActiveMQ假定任何带有内容长度标头的传入STOMP消息都是ByteMessage,任何没有该标头的消息都是TextMessage(参考资料)。

Ruby's stomp gem tries to take account of this, but the header encoding method they've implemented breaks their own tests for a custom header: :suppress_content_length, which does what it says on the tin.

Ruby的stomp gem尝试考虑到这一点,但是他们实现的头编码方法打破了他们自己的自定义头的测试:: suppress_content_length,它执行它在锡上的说法。

I've forked & modified their code to fix this - see my stomp repo - which hopefully they'll fold in soon enough.

我已经分叉并修改了他们的代码来解决这个问题 - 看看我的stomp repo - 希望他们很快就会折叠起来。

#1