qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: UTF8 / binary strings in dynamic languages
Date Wed, 25 Sep 2013 11:23:34 GMT
On Wed, Sep 25, 2013 at 09:34:17AM +0200, Jimmy Jones wrote:
>  On Thu, Sep 19, 2013 at 12:59:17PM -0400, Darryl L. Pierce wrote:
> > I modified the spout.pl example to do this for both the name and value
> > on properties pass in at the command line and they were seen by the Java
> > drain tool (yay!).
> > 
> > So, narrowing down the goal slightly, WRT QPID-5067, do we want to 1)
> > require the users to explicitly called utf8::upgrade() on the property
> > name and value and assume that, whatever they pass in is correct, or do we
> > 2) assume it for them and upgrade the string in our porcelain layer?
> > 
> > In this case, since message properties are always strings, the latter
> > seems to me to be the right path.
> 
> Can't message properties also be integers? Does the spec disallow binary?
> Having said that, 2 seems sensible to me.

I don't think it disallows them, and sorry I mean to say property names.

In my tests, if the property value is an integer or a float, then the property
is shown by the Java drain example properly so long as the name is UTF-8
encoded.

However, if the property value is a regular string, which is then VBIN
encoded, then Java doesn't see the property at all; i.e., it says there
are no properties even though one was provided.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/


Mime
View raw message