On 16/01/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Any string property set on the FieldTable class in the java client gets passed as a 'wide string' which is a new, non-standard type (the standard 'long string' value type doesn't seem to be used anymore in field table). So the strings in the client properties can't be understood by a broker that doesn't support that new type.
There is a method setAsciiString, which allows you to specify short strings. However I hadn't realised that use of setString was so widespread at the moment.
Perhaps as a quick fix to this particular problem we could make use of the non-standard types more explicit (e.g. setWideString() on the FieldTable class).
Yes, or I was going to change field table for the moment to use non-wide strings all the time (until we get the types approved and implemented in C++ and python etc.).
As I understand it, the most urgent use of these new types is in explicitly encoding the value types for all custom JMS properties. While I fully appreciate the desirability of this, I would also like to keep interoperability except where the application explicitly chooses to use non-standard extensions.
The main driver was not really strings (although the length limit on short string is an obvious issue) but for other types where we needed to know the "real" type so that we could apply the type conversion rules.
Maybe we could allow different strategies for mapping JMS message property values to AMQP field table values. For full JMS compliance it may be the non-standard approach is the most viable but many applications may be able to work with other schemes e.g. transmitting all properties as strings and converting them as and where necessary (I realise this is not fully compliant from a JMS perspective). If the strategies could be set via a system property, that would allow users to trade off between AMQP compliance and JMS compliance (we could even allow a name or value mangling hack where both could be supported albeit in a rather nasty way).
My first reaction is: is it worth spending time doing that rather than just getting the field table types updated in the protocol? We previously had a name mangling rule scheme that doesn't take you any further forward since you need to standardise those rules to achieve interop. I think there was general consensus that the original set of field table types was incomplete so it shouldn't be too difficult to get it approved. Martin typed up the proposal (which had originally be only in an email) and put it on the wiki when he was implementing the field table stuff: https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal RG
