This is related to my previous questions about packet extensions in IQ packets, and may be also related to the previous question (cnfiechter) re subpackets in IQ.
It was established previously that packet extensions did not work (currently) with IQ packets (due to the fact that they should only have one child element) - way to send it was to subclass IQ and override getChildElementXML…
Anyway also noticed that returning IQ packet objects don’'t seem to provide access to child element - even though it clearly does arrive looking at the debug window. toXML() just returns packet with no child, getChildElementXML returns empty string, and of course getExtensions returns an Iterator with 0 objects.
Am I still not getting something? Would this have been fixed along with the subpacket fix? BTW - did a fix ever go in re my previous question - i.e. to enabled addExtension with a 1 child limit? (Sorry - I’'ve not been keeping up with the daily builds)
While the current IQ spec says that it should have only one child element, many of the outstanding JEP’‘s have more than one child. Take, for example, JEP-0052 (File Transfer) which has many children, or JEP-0079 (Message Delivery Semantics). While none of these may be accepted by the Jabber Council, they are still available. To that end, I would not hard limit the getChildElementXML to 1 child node, simply because some of us are implementing these JEP’‘s and it doesn’'t really hurt to not have it limited.
While the current IQ spec says that it should have
only one child element, many of the outstanding JEP’'s
have more than one child. Take, for example, JEP-0052
(File Transfer) which has many children, or JEP-0079
(Message Delivery Semantics). While none of these may
be accepted by the Jabber Council, they are still
available. To that end, I would not hard limit the
getChildElementXML to 1 child node, simply because
some of us are implementing these JEP’'s and it
doesn’'t really hurt to not have it limited.
The XMPP spec makes it very clear that IQ packets can have only a single child element (but that child element could be a full XML snippet with as many children as it wants).
I actually rejected the packet extension idea for IQ’‘s because I thought it was a bit confusing API-wise. However, I did tighten up the logic and the Javadocs so that nobody will get confused about trying to add extensions to IQ’'s in the future.
In terms of IQ parsing – at the moment there isn’‘t such as a generic IQ packet like there is with DefaultExtensions. I’‘ll look into adding that for an upcoming release. At the moment, you’‘ll need to register an IQ provider or a JavaBean for any incoming IQ packets you want to be able to parse. The good news is that we’‘re adding providers for many of the important JEP’'s through the smackx package. For example, Gato has already completed work on message events and roster transfer.
Thanks for your reply - I’‘m a bit confused, I’‘ve not dealt with the provider package yet. I’'m really just looking to be able to grab the full IQ packet (including child element) as a String and just view it / parse it myself. Is there a simple way to do this? Or is it permenently dropped if the child element namespace is not known?
If it would help, I have an implementation of jabber:iq:oob that shows how the providers work… I could start up the work laptop and forward it to you. It may not help at all, but sometimes you never know.
Thanks for your reply - I’‘m a bit confused, I’'ve not
dealt with the provider package yet. I’'m really just
looking to be able to grab the full IQ packet
(including child element) as a String and just view
it / parse it myself. Is there a simple way to do
this? Or is it permenently dropped if the child
element namespace is not known?
The provider package is the way to go. It makes it very simple to handle any type of incoming IQ packet that you want to. If it’'s a simple IQ packet, you can even let Smack use bean introspection to set the properties of an object using the XML data. Please check out the Javadocs in the latest daily builds and let us know if you have questions. We should have a full provider guide in the upcoming 1.2 release as well.
Sorry to be a pain, but can somebody give me some simple example code for the provider architecture. I’'m getting quite confused with the fundamentals of it. (I have todays build 13th Aug)
For example lets just say I send the following packet:
(But like I say I cannot get accesss to this subpacket via the getXML method - or even by casting the Packet to IQ and using getChildElement XML)
What would be the minimum amount of code I need to get hold of the returning query packet? (Even just as one string) Its just for a quick temporary tool we require - nothing fancy!
Message was edited by: john begley
I worked out how to use the IQProvoder and have everything working now. Thanks.