On Thu, Dec 12, 2019 at 11:59 PM Timothy Bish <[email protected]> wrote:
> > which is then encoded (not quite optimal, but seems to be correct per the > > spec) as > > > > [0, 0, 0, 70, 2, 0, 0, 0, 0, 163, 16, 97, 109, 113, 112, 58, 97, 116, > 116, > > 97, 99, 104, 58, 108, 105, 115, 116, 208, 0, 0, 0, 38, 0, 0, 0, 14, 161, > 8, > > 118, 120, 45, 119, 101, 98, 45, 48, 67, 163, 6, 83, 101, 110, 100, 101, > > 114, 64, 64, 64, 161, 3, 82, 80, 67, 64, 64, 64, 64, 64, 64, 64] > > Your encoding appears to go wrong when encoding the Role value as the > encoding code appears to be (163) which is the encoding code for 'Char' > while Role is expected to be a Boolean type. > Thanks, I did miss that! This turned out not to fix the problem by itself. I previously didn't know exactly what to do with the way the spec documents source and target as being of the "*" type, but it turns out there are described types for both of these. Implementing these managed to get me to the next stage, where I get an attach performative returned from Artemis. I also discovered https://qpid.apache.org/amqp/type-reference.html, which is much easier to use than the spec PDF! Can you give me some pointers as to where in the source code this level of decoding happens for incoming message frames? That way, I might be able to better resolve similar problems in the future. Kind regards, Dirkjan
