[jira] [Commented] (AMQ-6192) Stomp frame translator not working when a content length is set

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173755#comment-15173755 ] 

Christopher L. Shannon commented on AMQ-6192:
---------------------------------------------

Using the content length is a simple way to check if it is a bytes message or should be converted using a transformer.  That being said, I don't see why the logic couldn't be changed to first check for a transformation header and to honor that if it exists before going the byte message route.  If that header is specifically set it seems like it would be best to honor that regardless of whether or not the content-length is set. (as you pointed out the spec says it should include it anyways)

[~tabish121], What do you think about this change?

> 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)