[
https://issues.apache.org/jira/browse/CAMEL-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495151#comment-13495151
]
Babak Vahdat commented on CAMEL-5718:
-------------------------------------
They are still failing even after the latest fix:
https://builds.apache.org/job/Camel.trunk.fulltest/1092/org.apache.camel$camel-smpp/#showFailuresLink
Not sure if this sounds reasonable to you but I think the problem in both cases
is the following line:
{code}
smppMessage.getBody(String.class).getBytes()
{code}
Which makes use of the platform's default charset for the byte array being
returned. However the other body is a UTF-8 encoded byte array! So I think the
usage of
{code}
IOConverter.toString(byte[] data, Exchange exchange)
{code}
could resolve the problem. To reproduce the problem on your local box you could
set the following system property while running the tests:
{code}
-Dfile.encoding=UTF-16
{code}
> Bodies of SMs with 8-bit data_coding are mangled
> ------------------------------------------------
>
> Key: CAMEL-5718
> URL: https://issues.apache.org/jira/browse/CAMEL-5718
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Reporter: Francois Kritzinger
> Assignee: Christian Müller
> Fix For: 2.9.5, 2.10.3, 2.11.0
>
> Attachments: 8bit_deliver_sm_bodies_mangled.diff,
> camel_smpp_8bit_messages.diff
>
>
> Bytes in the body of 8-bit SUBMIT_SMs which do not fall within the chosen
> charset's range are set to '?', which is obviously wrong because 8-bit/binary
> data should not be modified in any way.
> EDIT: Turns out the RX SMs (DELIVER_SM, etc.) were also affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
