Sounds good.
And btw I dont think there was a good reason for the String
conversion. It should have been bytes from the start.
On Wed, Apr 24, 2013 at 10:13 AM, Thomas Termin <thomas.ter...@gmail.com> wrote:
> 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
>>
--
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
