Is there a way to take a peek at all incoming traffic that Wildfire receives, before it attempts to parse things into packets? That is, intercept all XML as it is received?
I am getting IllegalArgumentExceptions and stacktraces in Wildfire whenever I log in with a (federated) Google Talk account (about 24-32 of them per login), but would like to see which way the packets flow. Because parsing them throws Exceptions, I cannot actually see the original XML.
By the way, the warning I am getting:
2006.11.14 10:56:43 Invalid presence show
java.lang.IllegalArgumentException: No enum const class org.xmpp.packet.Presence$Show.
at org.jivesoftware.wildfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:156)
at org.jivesoftware.wildfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 62)
Message was edited by: fvschie (changed title for a bit more descriptiveness)
As you noticed Wildfire prints the XML stanzas once parsed. Which client are you using? Some clients allow you to open a debugger window to trace exchanged XML packets with the server. That could be the easiest way to figure out what is going on. If you want to work from the server side then using Ethereal could be an option.
I have a small Smack-based client, with the excellent debugger window (thank you, whoever poured time into that one), and I’‘m not getting or sending any illegal Presence traffic. It only happens when a Google Talk user comes online or goes offline with me on their buddy lists. So I am assuming Google Talk is the guilty party, but can’‘t be sure. It’'d probably be in response to a presence probe, which is handled server-to-server only.
Server side, or rather, server-to-server side, everything is encrypted.
Which brings me back to trying to log all data. Probably not gonna happen. Anyone else having the same issue?
Okay, the original problem is solved, but it would still be nice if there were a facility in Wildfire that could dump XML bytes as received and sent, pre-parse, in some logfile. It would have made debugging this much easier and less guesswork.
: We’‘ve got a Jingle gateway that talks to Google Talk for us. GTalk once required Presence stanzas to have a element, even if none were required by the spec, or it would ignore the presence stanza’‘s wrt Jingle signalling. I’'m guessing Wildfire has two means of parsing: One to determine routing parameters (stanza type, to, from) and one that actually handles the packet. A helper plugin we made actually made a PacketInterceptor look inside the packets to redirect them, and that caused the exceptions, where normally the bad Presence stanzas would just be sent onwards. Weird, but true.