I have found that the first time I send a private message to a chat room, I receive an IQ message for the disco#info extension (not sure if it comes from OpenFire server or the Spark client on the other end). This is not necessarily a problem except I noticed the XIFF client does not reply to it (the spec requires that the receiver respond either with a result or an error, but XIFF does neither). I have enabled the InfoDiscoExtension. The problem is that when the IQ message is received, XIFF tries to create an instance of the extension class using a no-arg constructor … but it does not have one … it expects an xmlNode to be passed the constructor … so it fails.
I noticed most of the other extensions make this parameter (strangely called parent everywhere except the two disco extension classes where it is called xmlNode) optional. I have changed DiscoExtension, InfoDiscoExtension, and ItemsDiscoExtension constructors to make the xmlNode parameter optional and I am just beginning testing, but I wanted to post here as usual to see if anyone else has any comments on this.
I think this is another bug. Anyone disagree?
When I started using this I was told that although it was beta it was pretty solid and was being used in a number of production projects. I am a little surprised I am finding as many bugs in areas I would have thought someone would discover them already. Is this really being used by anyone else? If so, they must be using a very trivial set of functionality because I don’'t see how they could not be running into the same problems I have run into already.
Making the constructor parameter optional fixed the immediate problem, but it still doesn’‘t seem to be working correctly. Now, when the IQ query is received it is parsed and handled correctly up to the point that an IQEvent is dispatched, but nothing happens after that. I would have expected some part of the XIFF code to have registered interest in IQEvents so that a response (error or result) would be generated in response to the query, but nothing happens … the IQEvent just seems to disappear into the black hole. And I don’‘t think the expectation was that the client code should handle the IQEvent because a) the XMPPConnection doesn’‘t publish this as one of the events that it dispatches and b) it is part of the discovery protocol to generate some response so it just doesn’'t make sense to me that this should be the responsibility of the host client.
Honestly, has any of this code actually been tested? I feel like I’‘m having to modify almost every class to get this basic chat room client working. If I’‘m off base, someone please feel free to set me straight … but so far I feel a bit like I’'m talking to myself.
I have searched the entire code base for XIFF and I can find only four references to IQEvent … two in the class itself and two in the code that creates and dispatches the event.
I can’'t see anywhere in the code where there is any intent or attempt to respond to the disco#info query. What am I missing? Or does it just not do it?
I should point out that although the server doesn’‘t seem to be negatively affected by the lack of any response, the spec does say that some response MUST be returned. Is the intent here that every client should send their own response to this message? If so, why isn’'t IQEvent listed among the events published by XMPPConnection which is the class dispatching the event?
Can anyone shed light on how this was meant to work?