[
https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906883#comment-17906883
]
ASF subversion and git services commented on AMQ-8398:
------------------------------------------------------
Commit 3481f897bcfe0c0557d2dfd0400d366b7460824b in activemq's branch
refs/heads/6.1.x.AMF.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=3481f897bc ]
AMQ-8398 - Fix Stomp to OpenWire UTF-8 translation
This commit fixes conversion of messages that are sent or received
using Stomp when the body contains characters that require 4 bytes
for encoding using standard UTF-8.
ActiveMQ and OpenWire currently use a modified UTF-8
encoding that only uses 3 bytes so the conversion previously was
breaking because the body was encoded using standard JDK UTF-8 encoding
and set directly on an ActiveMQText message which was leading to
decoding errors later when the ActiveMQMessage tried to decode using the
modified encoder. The reverse was also was true and was breaking
in some cases.
The fix now makes sure to correctly decode the Stomp message back to a
String first and set that on the ActiveMQ message so it can be
re-encoded correctly. The reverse is fixed as well so both
conversion from Stomp -> OpenWire and OpenWire -> Stomp work. Tests have
been added for Stomp -> OpenWire, OpenWire -> Stomp, and Stomp -> Stomp
which is really Stomp -> OpenWire -> Stomp.
(cherry picked from commit 3ddf5155973f46b080ad4500000281e06ad8c372)
(cherry picked from commit 73a8d5ca67bd897d7b4ec05b13a5e7f450a13a4e)
> 4-byte Unicode message from JMS to STOMP will be corrupted
> ----------------------------------------------------------
>
> Key: AMQ-8398
> URL: https://issues.apache.org/jira/browse/AMQ-8398
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker, STOMP, Transport
> Affects Versions: 5.16.3
> Reporter: Simon Lundstrom
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 6.2.0, 5.18.6, 6.1.4
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> When sending a message from:
> JMS producer to STOMP consumer
> or
> STOMP producer to JMS consumer
> which contains a 4-byte unicode code points e.g.
> https://unicode-table.com/en/1F5A4/ there is a corruption of the message.
> In the JMS to STOMP case the code point gets converted to:
> {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}.
> and in the STOMP to JMS case the JMS client throws an exception:
> {code}
> Exception in thread "main" javax.jms.JMSException:
> java.io.UTFDataFormatException
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72)
> at
> org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104)
> at
> org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84)
> at testkonsument.App.JMS(App.java:86)
> at testkonsument.App.main(App.java:42)
> Caused by: java.io.UTFDataFormatException
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389)
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> at
> org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101)
> ... 3 more
> {code}
> Using 4-byte unicode points
> from STOMP to STOMP
> or
> from JMS to JMS
> is not a problem, both works and does not corrupt the code point.
> Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g.
> https://unicode-table.com/en/2614/) Unicode code points does NOT get
> corrupted, even if the same message includes a 4-byte Unicode code point.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
