XEP-0066 in Smack 4.4.3

[Moriarty]

Hi everyone,
I’m currently using Smack 4.4.3 and I’m facing a strange problem.
Unfortunately, Smack does not support the XEP-0066 (Out-of-Band Data) so I’m implementing my own class for the xep.

I can correcly upload the file and send the oob with the url, but when I receive it in the newIncomingMessage of IncomingChatMessageListener I got the error

FATAL EXCEPTION: Smack Cached Executor
java.lang.ClassCastException: org.jivesoftware.smack.packet.StandardExtensionElement cannot be cast to …

So I added this line before the connection initialization

ProviderManager.addExtensionProvider(“x”, “jabber:x:oob”, OutOfBandData.Provider())

Smack receives the stanza and my OutOfBandData.Provider correctly parse the message. But now the newIncomingMessage is not raised anymore!
I also tried addSyncStanzaListener to the connection (with filter Message::class) but still nothing happen.

Have you got some hints?

Thanks!

[Moriarty]

After a debug session, I found the root cause.

In the class org.jivesoftware.smack.provider.Provider.java there’s the method

public final E parse(XmlPullParser parser, XmlEnvironment outerXmlEnvironment)

This method calls the Provider I wrote for the Oob. Its parse method consumes the XmlPullParser till the end of the document (XmlPullParser.Event.END_DOCUMENT). Once finished, the provider super class calls the method

ParserUtils.forwardToEndTagOfDepth(parser, initialDepth);

And here comes the problem. This method executes a loop

while (!(event == XmlPullParser.Event.END_ELEMENT && parser.getDepth() == depth))

Due to the previously parsed XmlPullParser (from my Oob class), this become an endless loop.

I fixed this issue by adding a break in the parse of my Oob class. Now the parsing ends before the XmlPullParser.Event.END_DOCUMENT and the subsequent loop exits correctly.

That was a problem in my code, but maybe the forwardToEndTagOfDepth should check if the parser is already at the end of the document to improve robustness.

[Flow]

@Moriarty

That was a problem in my code, but maybe the forwardToEndTagOfDepth should check if the parser is already at the end of the document to improve robustness.

Isn’t that what firwardToEndTagOfDepth() already does? I am not sure if you have understood the root cause of your issue.

I also think that Smack has OOB support. But I am currently on vacation and can’t check the details yet.

[Moriarty]

Thanks Flow, I will be very happy to replace my code with the Oob of Smack. Which class should I use?

About the forwardToEndTagOfDepth, I’m just saying that it should also check for END_DOCUMENT other than END_ELEMENT.

[Flow]

@Moriarty

Thanks Flow, I will be very happy to replace my code with the Oob of Smack. Which class should I use?

Turns out that I was wrong. Smack has not yet support for OOB.

@Moriarty

About the forwardToEndTagOfDepth, I’m just saying that it should also check for END_DOCUMENT other than END_ELEMENT.

Now I understood you. It’s about END_DOCUMENT, when I read END_ELEMENT. I could imagine adding an assert statement that asserts that END_DOCUMENT does not appear (as it would break the methods API contract).

[Flow]

[core] Assert that 'event' is not END_DOCUMENT in forwardToEndTagOfDepth()