instead of String, which will always return null if used with
ocupantsMap.get(String), because String.equals(Object) is only true if
Object is also instanceof String.
Thanks to Adnan Elezovic for reporting.
And replace all instances where String.Builder.append() is called with a
String of length one with append(char).
Also adds StringUtils.toStringBuilder(Collection, String).
Instead of extending SocketFactory, the proxy support classes now
implement ProxySocketConnection. This removes a lot of unnecessary
code.
Also re-enables proxy support, which was broken in previous versions
because none of extended SocketFactories did override
createSocket() (SMACK-683).
if the connection is not connected in sendStanzaWithResponseCallback and
in PacketCollector.
Also decrease log level if roster result listener's exeption callback is
invoked with a NotConnectedException.
in afterFeaturesReceived. As this will cause
maybeCompressFeaturesReceived.reportSuccess() never to be called if the
server announces 'starttls' but security mode is set to 'disabled' and
if 'compression' is also announced.
Fixes SMACK-678.
A sequence of connect(), disconnect(), and connect() could cause the
connection to get disconnected again by the old reader thread, which was
blocking on disconnect because a closing stream tag was read. If the
second connect() was processed before the disconnect(), then the
connectin would get disconnected right after the second connect().
This showed up as a "strange" sequence of stanzas in the XMPP servers
log. Note that the stanza ID of the unavailable presence has a lower
number then the previous stanzas:
Jun 11 23:11:11 c2s18c2370 debug Resource bound: smack-inttest-two-93t70@geekplace.eu/two-93t70
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <iq id='qn03S-26' type='get'>
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <presence id='qn03S-27'>
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <presence id='qn03S-23' type='unavailable'>
Jun 11 23:11:11 c2s18c2370 debug Received </stream:stream>
This is because the disconnect() of the first reader thread could
generate the unavailable presence, but was blocked afterwards when
entering the synchronized disconnect(Presence unavailablePresence).
SMACK-633.
If such an exception ever happes when running a integration, then the
framework should not abort, but instead log the exception so that other
information is also logged.
