Return-Path: X-Original-To: apmail-camel-issues-archive@minotaur.apache.org Delivered-To: apmail-camel-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1D812D4D8 for ; Mon, 12 Nov 2012 08:34:20 +0000 (UTC) Received: (qmail 46288 invoked by uid 500); 12 Nov 2012 08:34:18 -0000 Delivered-To: apmail-camel-issues-archive@camel.apache.org Received: (qmail 45627 invoked by uid 500); 12 Nov 2012 08:34:14 -0000 Mailing-List: contact issues-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list issues@camel.apache.org Received: (qmail 45578 invoked by uid 99); 12 Nov 2012 08:34:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2012 08:34:13 +0000 Date: Mon, 12 Nov 2012 08:34:13 +0000 (UTC) From: "Babak Vahdat (JIRA)" To: issues@camel.apache.org Message-ID: <336311141.99617.1352709253229.JavaMail.jiratomcat@arcas> In-Reply-To: <259269576.1171.1350660491961.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (CAMEL-5718) Bodies of SMs with 8-bit data_coding are mangled MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CAMEL-5718?page=3Dcom.atlassian= .jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1349= 5151#comment-13495151 ]=20 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$ca= mel-smpp/#showFailuresLink Not sure if this sounds reasonable to you but I think the problem in both c= ases 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 c= ould set the following system property while running the tests: {code} -Dfile.encoding=3DUTF-16 {code} =20 > 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=C3=BCller > 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/bin= ary 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 administrato= rs For more information on JIRA, see: http://www.atlassian.com/software/jira