Hello Claus, Mike,
I can attach also the patch for mina2 this evening.
Thomas
On Wed, Apr 24, 2013 at 10:09 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> Yeah should also be done on camel-mina2.
>
>
> On Wed, Apr 24, 2013 at 8:23 AM, Mikael Fernandus Simalango
> <mika...@gmail.com> wrote:
> > 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
> >>
>
>
>
> --
> 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
>
