Hi Claus,
If such change is to be applied to MinaUdpProtocolCodecFactory, the
equivalent codec in camel-mina2, Mina2UdpProtocolCodecFactory should also
be patched so that it can reflect consistent default codec behavior.
Currently, the default udp codec in camel-mina2 also converts the byte into
String before encoding them in an IoBuffer.
Mina2UdpProtocolCodecFactory:
...
private IoBuffer toIoBuffer(Object message, CharsetEncoder encoder)
throws CharacterCodingException, NoTypeConversionAvailableException
{
String value = context.getTypeConverter().convertTo(String.class,
message);
if (value != null) {
IoBuffer answer =
IoBuffer.allocate(value.length()).setAutoExpand(true);
answer.putString(value, encoder);
return answer;
}
// failback to use a byte buffer converter
return
context.getTypeConverter().mandatoryConvertTo(IoBuffer.class, message);
}
..
Patch should be similar with the one provided by Thomas. Yet, I'm somewhat
curious about the reason to convert to the bytes into string in the default
udp codec encoding logic. There must be a reason why it was designed that
way.
Regards,
Mike
On Mon, Apr 22, 2013 at 6:18 PM, 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
>
