On 20/12/16 18:20, Keith W wrote:
On 20 December 2016 at 10:14, Gordon Sim <[email protected]> wrote:
On 19/12/16 15:57, Keith W wrote:
By debugging the Java Broker's translation module, I can see that the
AMQP 1.0 publishing end is sending the map encoded within a
DataSection. This surprises me - I was expecting the application-data
to be an amqp-value containing the map. The Java Broker doesn't know
how to translate this for the 0-10 and hence the test fails.
Why does Qpid Python / swigged client encode the map this way?
The swig layer has some special logic for managing message content that
predates 1.0 and works the same way for both 1.0 and 0-10. The content-type
is used to indicate the type in both cases.
1.0 required some changes to the messaging API (set-/get- ContentObject())
to allow value sections to be used. I suspect the swig binding was just
never changed to use those changes.
Thanks Gordon for the swift reply. That all makes sense and I was
able to find the code concerned. It matches your suspicions.
Do you know if the bindings are due to have their AMQP 1.0 support refreshed?
I don't know of any such plan. The swigged client is really only used
for tests at present.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
