[
https://issues.apache.org/jira/browse/AMQ-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173790#comment-15173790
]
Timothy Bish commented on AMQ-6192:
-----------------------------------
The historical treatment of content-length as the indicator of BytesMessage
drives all this. If we decide that it's time to move away from that then I
think we should revisit all cases both on transformation and on the
content-type handling and come up with something consistent.
It'd be nice to move to a solution were content type drove everything but we do
need to keep legacy client's in mind when changing anything.
> Stomp frame translator not working when a content length is set
> ---------------------------------------------------------------
>
> Key: AMQ-6192
> URL: https://issues.apache.org/jira/browse/AMQ-6192
> Project: ActiveMQ
> Issue Type: New Feature
> Components: stomp
> Affects Versions: 5.13.1
> Reporter: Nigel Sim
>
> The stomp frame translator, such as "transformation:jms-map-json" is ignored
> if the content-length header is set, so you end up with an
> ActiveMQByesMessage instead of a ActiveMQMapMessage. The spec says this
> header is optional, but recommended, so I'm not sure why it's presence or
> absence is used to determine whether to try the frame translators.
> The code in question is in
> org.apache.activemq.transport.stomp.JmsFrameTranslator.convertFrame which
> says:
> {code}
> if (headers.containsKey(Headers.CONTENT_LENGTH) ||
> transformation.equals(Transformations.JMS_BYTE.toString())) {
> msg = super.convertFrame(converter, command);
> } else {
> // apply frame translator
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
