Done.
https://issues.apache.org/jira/browse/CAMEL-6302
On Mon, Apr 22, 2013 at 11:18 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> Yeah udp should keep the data as byte[]. Fell free to log a JIRA and
> work on a patch.
> eg just change to use byte[] as that makes the most sense for UDP.
>
> On Mon, Apr 22, 2013 at 11:16 AM, Thomas Termin <thomas.ter...@gmail.com>
> wrote:
> > Hi,
> >
> > no I don't use ByteBuffer as body type. The easiest example what I did is
> > to create the following route:
> > <from uri="mina:udp://localhost:2002?sync=false"/>
> > <to uri="mina:udp://localhost:2000?sync=false"/>
> >
> > 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 <claus.ib...@gmail.com>
> 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 <thomas.ter...@gmail.com
> >
> >> 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 <claus.ib...@gmail.com>
> >> 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 <
> thomas.ter...@gmail.com
> >> >
> >> >> 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: cib...@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: cib...@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: cib...@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
