I have prepared a minimal working example to reproduce this bug here.
Try to publish the user location from XEP-0080 Example 1 (No link since new users can only use 2 links) using a different client. I used the XML console of gajim.
java.lang.IllegalStateException: Illegal to call getName() when event type is CHARACTERS. Valid states are START_ELEMENT, END_ELEMENT
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.getName(XMLStreamReaderImpl.java:998)
at org.jivesoftware.smack.xml.stax.StaxXmlPullParser.getQName(StaxXmlPullParser.java:124)
at org.jivesoftware.smack.xml.stax.StaxXmlPullParser.getName(StaxXmlPullParser.java:118)
at org.jivesoftware.smackx.pubsub.provider.ItemProvider.parse(ItemProvider.java:59)
at org.jivesoftware.smackx.pubsub.provider.ItemProvider.parse(ItemProvider.java:44)
at org.jivesoftware.smack.provider.Provider.parse(Provider.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.parseExtensionElement(PacketParserUtils.java:834)
at org.jivesoftware.smack.util.PacketParserUtils.addExtensionElement(PacketParserUtils.java:933)
at org.jivesoftware.smack.util.PacketParserUtils.addExtensionElement(PacketParserUtils.java:928)
at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:104)
at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:85)
at org.jivesoftware.smack.provider.Provider.parse(Provider.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.parseExtensionElement(PacketParserUtils.java:834)
at org.jivesoftware.smack.util.PacketParserUtils.addExtensionElement(PacketParserUtils.java:933)
at org.jivesoftware.smack.util.PacketParserUtils.addExtensionElement(PacketParserUtils.java:928)
at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:104)
at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:85)
at org.jivesoftware.smack.provider.Provider.parse(Provider.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.parseExtensionElement(PacketParserUtils.java:834)
at org.jivesoftware.smack.util.PacketParserUtils.parseMessage(PacketParserUtils.java:186)
at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.java:111)
at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(AbstractXMPPConnection.java:1448)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000(XMPPTCPConnection.java:130)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:969)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936)
at java.base/java.lang.Thread.run(Thread.java:833)
The issue seems to be in the org.jivesoftware.smackx.pubsub.provider.ItemProvider class and is caused by whitespace in the item. For example receiving following item does not result in a crash:
If the child of an XML element consists of text and further elements, then this is called āmixed contentā. XMPP explicitly forbids mixed content in a few places (cf. RFC 6121 Ā§ 5.2.3) and I believe that your with the mixed content of a whitespace-only text and an <geoloc/> element would not pass XEP-0060ās schema definition. Furthermore, it is unclear how the textual part of the mixed content can be used, or even, if it should be used.
On the other hand, the schema of a XEP is largely seen as informal and I canāt find any formal explicit statement that forbids mixed content here.
I am currently torn on this. My policy is to not add changes to Smack that support non-standard behavior. At least not as part of my spare time work on Smack, and not without those being configurable and default to off. I may have to think about this a little longer, but right now, I lean towards not changing Smack into accepting this.
Do you have any information about the implementation on the orginating entity that procudes this <item/>? Irregardless of Smack accepting or not accepting this, you may want to inform the people behind the implementation to change this behavior.
Is the order/frequency in which white space characters (newlines, spaces, tabs) appear in between elements relevant, when there are no other characters than white space characters? In other words: is newline space space significantly different from newline space space newline space space in that regard?
I donāt think so, the order is not relevant. But from XMLās perspective, they all, newlines, spaces, tabs, all other whitespace and non-whitespace characters, add character data to the elementās content.
My question only makes much sense if the original stanza, that is not causing the issue, is being exchanged with Smack exactly as shown here. If what is shown here on Discourse is a pretty-printed representation of data that was transmitted without any mixed content, then my question is primarily adding confusion.
The orginating entity in this case would be the Prosody PEP service. I feel like whitespace should just be ignored (i.e. only throw an exception when non-whitespace is encountered).
Both stanzas are copy-pasted from the output I get when I set SmackConfiguration.DEBUG = true.
I could also imagine that Prosody just shoves āitemsā that are published into the node verbatim. Hence the causing entity could be the item publishing one.
The XML level makes no distinction if itās whitespace or not. Itās just character data, together with an element, and hence mixed content.
That said, Iāve just created SMACK-919 for this.
Iām noticing this exception in my logs after updating Spark to Smack 4.4.4. Iāve redacted the JIDs to protect the innocent. Is this related?
java.lang.IllegalStateException: Illegal to call getName() when event type is CHARACTERS. Valid states are START_ELEMENT, END_ELEMENT
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.getName(XMLStreamReaderImpl.java:938)
at org.jivesoftware.smack.xml.stax.StaxXmlPullParser.getQName(StaxXmlPullParser.java:123)
at org.jivesoftware.smack.xml.stax.StaxXmlPullParser.getName(StaxXmlPullParser.java:117)
at org.jivesoftware.sparkimpl.profile.ext.VCardUpdateExtension$Provider.parse(VCardUpdateExtension.java:75)
at org.jivesoftware.sparkimpl.profile.ext.VCardUpdateExtension$Provider.parse(VCardUpdateExtension.java:62)
at org.jivesoftware.smack.provider.Provider.parse(Provider.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.parseExtensionElement(PacketParserUtils.java:834)
at org.jivesoftware.smack.util.PacketParserUtils.parsePresence(PacketParserUtils.java:477)
at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.java:115)
at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(AbstractXMPPConnection.java:1457)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000(XMPPTCPConnection.java:130)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:969)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936)
at java.lang.Thread.run(Thread.java:748)
Itās hard to tell if itās fixed by SMACK-919 without a stacktrace that provides some context where this is happening. It is likely related in the sense that this is the same class of coding error (which should be trivial to fix).
Sorry, Iām running in and out of meetings without properly giving this the details that it needs. Iāve edited my previous message to include the stacktrace.