"Use the source, Luke (and study the relevant open standard)" Obi-Wan Kenobi
Smack is open soure, so let us look at the source: One interesting part is
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
which reads
Map<Resourcepart, Presence> entityPresences = presenceMap.get(entity);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L374
We also find that presenceMap
is declared as follows
private final Map<BareJid, Map<Resourcepart, Presence>> presenceMap = new ConcurrentHashMap<>();
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L168
So it is a ConcurrentHashMap
, which matches with the stacktrace. It is obvous that entity
above is null
, which is the cause of the NullPointerException
.
Now we need to walk the call stack up (or down, depening on your point of view), to determine where entity
origins from. Here the interesting part is
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
which reads
userPresences = getOrCreatePresencesInternal(key);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
so enitty
is key
here. Which is declare and define just a few lines above
final BareJid key = from != null ? from.asBareJid() : null;
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
So in case from
is null,
keywill also be null. Which later causes the
NullPointerException. Looking at the code, we find that this is caused by a presence XMPP stanza without a
from` attribute set.
The question is now if those stanzas are legal in XMPP. To determine that, we need to have a look at the specification. The relevant part is [RFC 6120 § 8.1.2.1 4.],1, which states
When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (localpart@domainpart).
So a missing 'from' attribute is generally allowed and is equal to the "account's bare JID".
Now the question is: Are there any presence stanzas specified send from the server to the client which do not have a 'from' attribute? I could not find any while reading the related RFC 6121. And I am not aware when this should ever happen (I possibly could be missing someting). But right now this appears to be a bug in the entity which creates those presence stanzas, which is the used XMPP server implementation.
(What XMPP server implementation do you use?).