Done for mina2 either.

On Wed, Apr 24, 2013 at 10:22 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:

> 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
>

Reply via email to