You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Thomas Termin <th...@gmail.com> on 2013/04/18 13:35:34 UTC
MinaUdpProtocolCodecFactory
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
Re: MinaUdpProtocolCodecFactory
Posted by Mikael Fernandus Simalango <mi...@gmail.com>.
Hi Thomas,
As far as I reckoned, MinaUdpProtocolCodecFactory is the default UDP codec.
What we did to prevent this codec from being called is by setting
allowDefaultCodec=false and codec=#customCodec in the mina endpoint URL.
Otherwise, you can also extend the mina component and when doing so, you
can set the values of some URI parameters to predefined values in the the
endpoint creation logic.
Regards,
Mike
On Fri, Apr 19, 2013 at 3:43 PM, Claus Ibsen <cl...@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 <th...@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 <cl...@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.termin@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Thomas Termin <th...@gmail.com>.
Done for mina2 either.
On Wed, Apr 24, 2013 at 10:22 AM, Claus Ibsen <cl...@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 <th...@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 <cl...@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> Yeah should also be done on camel-mina2.
> >>
> >>
> >> On Wed, Apr 24, 2013 at 8:23 AM, Mikael Fernandus Simalango
> >> <mi...@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 <cl...@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.termin@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.ibsen@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.termin@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.ibsen@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.termin@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: cibsen@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: cibsen@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: cibsen@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Claus Ibsen <cl...@gmail.com>.
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 <th...@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 <cl...@gmail.com> wrote:
>
>> Hi
>>
>> Yeah should also be done on camel-mina2.
>>
>>
>> On Wed, Apr 24, 2013 at 8:23 AM, Mikael Fernandus Simalango
>> <mi...@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 <cl...@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.termin@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 <cl...@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.termin@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.ibsen@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.termin@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: cibsen@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: cibsen@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: cibsen@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: cibsen@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: MinaUdpProtocolCodecFactory
Posted by Thomas Termin <th...@gmail.com>.
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 <cl...@gmail.com> wrote:
> Hi
>
> Yeah should also be done on camel-mina2.
>
>
> On Wed, Apr 24, 2013 at 8:23 AM, Mikael Fernandus Simalango
> <mi...@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 <cl...@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.termin@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 <cl...@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.termin@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.ibsen@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.termin@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: cibsen@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: cibsen@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah should also be done on camel-mina2.
On Wed, Apr 24, 2013 at 8:23 AM, Mikael Fernandus Simalango
<mi...@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 <cl...@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 <th...@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 <cl...@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.termin@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 <cl...@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.termin@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: cibsen@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: cibsen@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: cibsen@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: MinaUdpProtocolCodecFactory
Posted by Mikael Fernandus Simalango <mi...@gmail.com>.
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 <cl...@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 <th...@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 <cl...@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.termin@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 <cl...@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.termin@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: cibsen@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Thomas Termin <th...@gmail.com>.
Done.
https://issues.apache.org/jira/browse/CAMEL-6302
On Mon, Apr 22, 2013 at 11:18 AM, Claus Ibsen <cl...@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 <th...@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 <cl...@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.termin@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 <cl...@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.termin@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: cibsen@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Claus Ibsen <cl...@gmail.com>.
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 <th...@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 <cl...@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 <th...@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 <cl...@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.termin@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: cibsen@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: cibsen@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: MinaUdpProtocolCodecFactory
Posted by Thomas Termin <th...@gmail.com>.
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 <cl...@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 <th...@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 <cl...@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.termin@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: cibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Claus Ibsen <cl...@gmail.com>.
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 <th...@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 <cl...@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 <th...@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: cibsen@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: MinaUdpProtocolCodecFactory
Posted by Thomas Termin <th...@gmail.com>.
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 <cl...@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 <th...@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: MinaUdpProtocolCodecFactory
Posted by Claus Ibsen <cl...@gmail.com>.
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 <th...@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen