powered by Jive Software

Child Element in IQ packet

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).

-Matt

John,

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.

Regards,

Matt

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?

does IQ.toXML() do what you need?

Message was edited by: dataknife (must complete thought BEFORE posting)

no, the toXML method just seems to return the IQ packet text without the child element.

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.

John,

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.

Regards,

Matt

I’‘ll check the lastest build or maybe wait until 1.2. Thanks both for your help, I’'ll let you know if I have any trouble with the provider package.

I can’'t find the daily builds?? Have they moved?

They are still there at http://www.jivesoftware.com/xmpp/smack/dailybuilds.jsp

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:

<iq type="get", id="jb">
<query xmlns=''john:iq:admin''>
<users><getallusers/></users>
</query>
</iq>

Currently I am registering a packet-listener with the connection object.

The following packet comes back:

<iq type="result" iq="jb">
<query xmlns=''hcl:iq:admin''>
<users>
<item name="john">
<item name="mary">
..
</users>
</query>
</iq>

(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.