I can see, on an incoming event message, that parsePacketExtension() finds no extension provider. It therefore proceeds to parse the tag as a DefaultPacketExtension (line 738, PacketParserUtils.java).
It recognises as a start tag at line 742.
Now… here is a nasty bug:
— The next parser ‘event’ is pulled at line 750. (causing to be ignored)
— The if() on the following line expects a TEXT event, but the parser event is a new START_TAG ().
— the loop is continued, without further processing, ignoring and pulling a new tag at line 743 (the parser is now looking at part of my payload: the tag).
— again, not being TEXT, loop continues, ignoring start tag
— pulls start tag at line 743
— again, not TEXT, ignores
— pulls a TEXT event at line 743, but the test on line 742 expects a start tag, and so this text is ignored (the contents of element)
— pulls an end tag at line 743
— recognises the end tag at line 757
— this element name (time) does not match elementName (event) and so the loop continues
— pulls another start tag at line 743 ()
— pulls a TEXT event at line 750
— recognises it in the if at line 751
— extension.setValue(“print”, “…text of print element…”) at line 753
— eventually it pops enough END TAGs to match at line 757+758 and finally exit the loop.
…and that is how we end up with a single, bogus, “print” element.
So that parser logic seems to need fixing, as it is missing the tag, getting out of sync, and ploughing into the payload, leaving the Packet without a useful extension.
XEP-0060 has as a child of and as a child of , but parsePacketExtension() is not prepared to handle a structure of this form:
Rather, it expects:
terminating when /TAG matches the extension tag name (event).
Worse, it only attaches extension data which is in the form of element text content. XML inside does not conform to this expectation.
Message was edited by: Toby Thain