OK, looks like this is a small bug in the proton codec where I haven't updated it to include the "empty list" optimised encoding that was introduced after I originally wrote the codec... and seems like the implementations we've been testing against don't use that optimised encoding...
If I can drink enough coffee to stay awake this afternoon then I shall try to fix it... Fixing the codec to generate better error messages is a task for another day :-) Apologies -- Rob On 2 July 2012 22:52, Rafael Schloming <[email protected]> wrote: > I took a quick look at this. I believe you're hitting a particularly > unfriendly issue with the way the java decoder works. Obviously it's > telling you a mandatory field is missing, but not which one. I know Rob > is planning on fixing that to be more friendly, however he is (or will > shortly be) on a plane back to Germany. If you run the same frames > through proton-c you might get more of a clue what's going on, and I > could definitely help out a bit more. Otherwise Rob should be back at > work late Tuesday/early Wednesday. > > --Rafael > > On Mon, 2012-07-02 at 11:32 -0400, Hiram Chirino wrote: >> Hi, >> >> I've been trying to see if I could use the Proton java codecs to parse some >> TCP dumps that I took of the SwiftMQ AMPQ 1.0 client when run a SwiftMQ >> server and there seems to be a couple frames where it blows up on. I was >> hoping someone could give me an idea why. If you guys want to checkout the >> test case, just my git branch from github: >> https://github.com/chirino/proton >> >> and then run maven in the base directory using: >> mvn compile exec:java >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
