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

Reply via email to