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/
pgpfIMSlgD1g5.pgp
Description: PGP signature
