To prevent
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:788)
at java.util.HashMap$KeyIterator.next(HashMap.java:815)
at org.jivesoftware.smackx.ping.PingManager.pingMyServer(PingManager.java:252)
at org.kontalk.service.msgcenter.MessageCenterService$3.run(MessageCenterService.java:1114)
at java.lang.Thread.run(Thread.java:818)
Thanks to Daniele Ricci for reporting this.
instead of an EntityFullJid, because according to XEP-0045 § 7.8.1.:
"The <room@service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant
JID of the inviter …"
The jids list doesn't have to be lazy initialized, because every IQ of
that type is guaranteed to contain at least one JID.
Also use ParserUtils.getJidAttribute().
for the last message. We now count the number of messages we want to
retrieve, and don't wait for another message if we have already
received all.
Thanks to King Jeong Hun for reporting this.
capturing all outoing presences of type 'available' would also capture
presences not used for presence broadcast, e.g., MUC presences.
This caused the EntityCaps integration test (localEntityCaps) to fail
if the MUC integration test was run before.
the manager must use a copy of the BlockListIQ's JID list, since it may
be the empty list which is not modifiable.
Also rename the getter methods from getJids() to getBlockedJids().
and not by '!error' as this there are presence stanzas containing the
muc#user namespace also send to the client, which results in a
ClassCastException in the StanzaListener.
Returning a boolean is not really expressive in such cases. For example,
if it returns 'false' then the callee has no information *what* went
wrong. Instead throw an SmackException with some more information.
A unauthorized user sents a update room subject message which is
rejected by the server. It responds with an error message which
is not picked up by the ChangeSubjectListener.
Mostly remove the helper utils. The server is required to present the
client with a consisent state of the block list and corresponding
modifications, so we should not end up with duplicate entires if we
don't check for them.
SMACK-731
Smack's previous entity caps implementation assumed that an entity lost
its entity caps feature as soon as a presence without caps from that
entity was received. But according to XEP-0115 § 8.4, this is a
perfectly normal optimization technique. We now reset the caps state
after an available presence becomes unavailable.
Also introduce PresenceEventListener, which is required for this
feature.
Also make Roster.preApprove() take a BareJid as argument.
Fixes SMACK-723.
