Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 896ED10345 for ; Mon, 22 Apr 2013 09:16:40 +0000 (UTC) Received: (qmail 24305 invoked by uid 500); 22 Apr 2013 09:16:40 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 23989 invoked by uid 500); 22 Apr 2013 09:16:39 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 23974 invoked by uid 99); 22 Apr 2013 09:16:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Apr 2013 09:16:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of thomas.termin@gmail.com designates 209.85.223.171 as permitted sender) Received: from [209.85.223.171] (HELO mail-ie0-f171.google.com) (209.85.223.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Apr 2013 09:16:35 +0000 Received: by mail-ie0-f171.google.com with SMTP id e11so6815234iej.16 for ; Mon, 22 Apr 2013 02:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=GmrurACblIfXe1RINJvcGLib+LW22j9LRkKCBD8M3H4=; b=SbDGmqo7LYGAznxB4l39dUKTZKPUx7RX5ySw8mWQLVxHWuc+dNWER0mB987ze7KaFG vrsb0xM1zPrlNGDXubwbk0F+em4cKOupnqxaGazjgO+PmZcLUX2EwkCUyGPVrlsWAtUT YbG1Uf0icas6OSSZXHXxrUqZ/zOP1NyRPPkjUgw0hz1XoKEHDjDjSJ0ETPg+QZFg+JWq B2bZF4zUX0yjIB8YTVYQLVpZ634ZnjVxAiev+n+4bK/Ht8JEE9V0pfStOD9kHIhRtejg D8866sENjhGKWCZnSQq5SX3S7lQDzOCyeaubyuTe2twQiTvBFWpnzl9nPUiRSzBMh4zD K/NQ== MIME-Version: 1.0 X-Received: by 10.50.192.201 with SMTP id hi9mr20791206igc.48.1366622175233; Mon, 22 Apr 2013 02:16:15 -0700 (PDT) Received: by 10.43.89.7 with HTTP; Mon, 22 Apr 2013 02:16:15 -0700 (PDT) In-Reply-To: References:

Date: Mon, 22 Apr 2013 11:16:15 +0200 Message-ID: Subject: Re: MinaUdpProtocolCodecFactory From: Thomas Termin To: users@camel.apache.org Content-Type: multipart/alternative; boundary=14dae9340d2f4c0e6904daef853c X-Virus-Checked: Checked by ClamAV on apache.org --14dae9340d2f4c0e6904daef853c Content-Type: text/plain; charset=ISO-8859-1 Hi, no I don't use ByteBuffer as body type. The easiest example what I did is to create the following route: Just route it from on port to another port on the same host. Nothing between it. The MinaUdpProtocolCodecFactory on the consumer side decodes it from an udp datagram to a byte[]. byte[] bytes = context.getTypeConverter().convertTo(byte[].class, in); On the provider side where it gets back to the wire it gets converted to a string: String value = context.getTypeConverter().convertTo(String.class, message); and then set to the ByteBuffer with the given charset. The result is that the original datagram is not anymore valid. What I thought what would be right is, to not convert it to a String but leave it as a byte array and put it into the ByteBuffer. I know of course that I can create an own codec. I do it currently to get the route work but I thought it would be not necessary to just route UDP datagramms. Cheers, Thomas On Fri, Apr 19, 2013 at 8:43 AM, Claus Ibsen wrote: > Hi > > You can always create your own codec and use that. > > And do you really use ByteBuffer as the body type? That is a Mina type? > > What we can do is to check the type of the body. If its already a > ByteBuffer then use it as is. > Otherwise we can try converting to byte[] and String. Which we need to > create the ByteBuffer. > > > > > > On Thu, Apr 18, 2013 at 5:17 PM, Thomas Termin > wrote: > > Hi Claus, > > > > yeah it is the camel-mina. Sorry. > > > > We could make this configurable within the camel uri. Something like > > encode=raw or whatever. Let me know if I should provide a fix/patch or > > whatever. > > > > Cheers, > > Thomas > > > > > > On Thu, Apr 18, 2013 at 3:29 PM, Claus Ibsen > wrote: > > > >> Hi > >> > >> Yeah it should probably be byte[] instead of a String. > >> > >> And I assume you refer to camel-mina ? > >> > >> On Thu, Apr 18, 2013 at 1:35 PM, Thomas Termin > > >> wrote: > >> > Hello, > >> > > >> > is there a special reason, that the MinaUdpProtocolCodecFactory encode > >> > method always try to convert the message body to a string? Is there a > way > >> > to avoid the conversion to a String? I would need the falilback method > >> > which is a conversion to a ByteBuffer. It would be nice to have that > >> > configurable. > >> > > >> > String value = context.getTypeConverter().convertTo(String.class, > >> message); > >> > if (value != null) { > >> > ByteBuffer answer = > >> > ByteBuffer.allocate(value.length()).setAutoExpand(false); > >> > answer.putString(value, encoder); > >> > return answer; > >> > } > >> > > >> > // failback to use a byte buffer converter > >> > return context.getTypeConverter().mandatoryConvertTo(ByteBuffer.class, > >> > message); > >> > > >> > Cheers, > >> > Thomas > >> > >> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> Red Hat, Inc. > >> FuseSource is now part of Red Hat > >> Email: cibsen@redhat.com > >> Web: http://fusesource.com > >> Twitter: davsclaus > >> Blog: http://davsclaus.com > >> Author of Camel in Action: http://www.manning.com/ibsen > >> > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cibsen@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > --14dae9340d2f4c0e6904daef853c--