Trying to write a smack IQProvider that parses an IQ Error stanza with sender XML

Smack Smack Dev
#1

I’m using smack 4.1.4, and I’m having trouble parsing an IQ Error stanza.

According to the spec @ Extensible Messaging and Presence Protocol (XMPP): Core an error stanza is of the form …

[RECOMMENDED to include sender XML here]

<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='langcode'>

  OPTIONAL descriptive text

</text>

[OPTIONAL application-specific condition element]

So, I’ve got two packets which may look something like …

A standard result IQ stanza looks something like …

… rest of result XML …

<error …

Whilst an error IQ stanza looks very similar (as it includes the sender XML)

… rest of sender XML …

<error …

And I can’t work out how to write a IQProvider for it. My problem is that there’s no way in advance of knowing if it’s an error or result IQ; the IQProvider class that I’m extending doesn’t give me access to the parent element, so I can’t check the IQ type attribute. If I read the next item after the end of the command tag to see if it’s an , then for the result IQ stanza I’ve just pulled the item and the Provider.parse() blows up when it calls ParserUtils.forwardToEndTagOfDepth(…) as we’ve gone too far already.

I’m sure it must be possible to properly parse an error IQ of this style, but I can’t figure out - can someone point me in the right direction?

Thanks,

Greg

#2

Whilst looking at another issue, I realised that this can be simplified somewhat.

If the packet structure is (somewhat simplified, but should give the idea)

<iq …>

<command …>

<tag-1>...</tag-1>

<optional-tag-2> ... </optional-tag-2>

Then the current IQ Provider does not (as far as I can see) allow you to parse - you need to call parser.next() after parsing to see if it optional-tag-2 is present. If it’s not present, then the custom provider has pulled too much off the pull parser, (I.e. the item in the above example).

How is it possible to work around this?

Thanks.

#3

Why shouldn’t this be possible? This is done in a dozen places in Smack. See for example smackx.iqversion.VersionProvider and compare it with XEP-92 Example 1.

#4

Yes, you’re quite right; my simplified second version was actually solvable (and after a decent nights sleep I figured out what should have been obvious).

However, my issue stills stands regarding parsing an IQ Error packet with the sender XML included; I can’t determine a way to parse the sender XML and the error information - and the default IQ Error packet ignores the sender XML.

#5

and the default IQ Error packet ignores the sender XML.
Right, that is not parsed. You already know how your IQ request XML looked like, why would you want the information again?

#6

In an ideal world, I wouldn’t want that information again. But given that I do, I can’t see a way to parse it …