by extending Manager.
Because FileTransferNegotiator will hold a strong reference to the
StreamNegotiators, which will eventually prevent XMPPConnection from
being GC'ed if no weak references in StreamNegotiator are used.
Thanks to Werner Glanzer for pointing this out.
Daniele Ricci reporting the following NPE using Smack 4.1.9
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.String.indexOf(int)' on a null object reference
at org.jxmpp.util.XmppStringUtils.parseBareJid(XmppStringUtils.java:124)
at org.jivesoftware.smack.roster.Roster$RosterPushListener.handleIQRequest(Roster.java:1416)
at org.jivesoftware.smack.AbstractXMPPConnection$2.run(AbstractXMPPConnection.java:1061)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
This is possibly caused by a service sending roster pushes for unbound
connections, i.e. where getUsers() returns 'null'. We now log such
situations instead throwing an NPE.
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.
We can't always setup the carbons listener in the constructor of the
manager, as the our local XMPP address may not be available yet. So
setup the carbons listener on a connection listener *and* in the
constructor.
I'm not sure why i've put the removeAsyncStanzaListener() call into
the finally block. If callback.processStanza(Stanza) takes a long
time (or even blocks), then it would appear to the "no response"
handling Runnable as if there was no response, when in fact there was
one.
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().
