Problem 1: Qpid.Client.Message.QpidHeaders is equivalent to org.apache.qpid.client.message.JMSHeaderAdapter in the Java code. It prepends the header field types onto the property names which the Java code no longer does. Sending a message with a field table from .Net to Java confuses the Java because it gets the property names wrong. I'm bringing QpidHeaders inline with the Java code at the moment so I'll patch that one soon enough.
Problem 2: Sending a header field from Java to .Net causes NotImplementedException at Qpid.Buffer.FixedByteBuffer, line 178 (slice method). Not sure of the cause of this yet but will be investigating soon. Yes, I see what you mean about lack of tests and dependencies. I'll follow your approach of changing as little as possible, and documenting as I go for the moment. Rupert On 2/23/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
Hi Rupert, > I've been trying to get the .Net and Java clients passing field tables > to each other and ran into a NotImplementedException in the > Qpid.Buffer.FixedByteBuffer class in the slice method. I fixed a few of those when doing my AMQTypes work, but I'm sure they were not all. > This has lead > me to start taking a more in depth look at some of this buffer stuff, > which as you rightly point out Tomas is a bit of a mess. I'm wondering > why a FixedByteBuffer wraps a HeapByteBuffer and why we have all these > different buffer implementations. It looks to me like this stuff has > been ported over as a quick and dirty hack from Mina code. Yep. That's my thought as well. > Tomas, I'm just wondering if you've done anything with any of this yet > or just left it well alone (I certianly don't blame you)? There's one reason I didn't touch much of it, except the bare minimum I had to do to get some of the native type serialization (typed and untyped integers) to work. Some reasons why I haven't done significant work here was that a) I'm pretty sure I didn't understand it all, b) it has 0 unit tests, making it hard to touch without screwing things up and c) there are some dependencies on that stuff from the generated code, which I didn't want to break. I do think it's a fantastic idea to get rid of any complexity there and get something simpler and fully tested + implemented. > I'm planning > to go through it all , document it so that I can comprehend it, > hopefully just make a few small changes to the field table stuff > working asap and then we can decide how to refactor it into something > sensible beyond that. That sounds good. Since I did part of the field table rewrite work, I'm fairly familiar with that part, so if you tell me more exactly what's the problem you're having with, I'd be happy to help out in clearing it up. Ping me via the list or my email and we can work on it together if you want (if you want to IM or something let me know as well). Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
