I am not happy with the concept of a build system wrapper, not to say
that I despise it. There is no reason why a single machine couldn't
have multiple versions of a build system-wide installed, and there is
no reason why each developer should download an individual copy of a
build system into the developers home directory. But here we are…
This option is meant a quick and dirty hack until
XMPPConnection.sendStanza() throws a dedicated Exception in case the
connection's outgoing queue is full.
The lambda we schedule in 25ms captures a strong reference to the
XMPPConnection. However the lambda is part of the scheduled action,
which we save in the renewEntityCapsScheduledAction field. This causes
a memory leak, since the ServiceDiscoveryManager now holds a strong
reference to its XMPPConnection.
Fix this by obtaining the strong reference to the XMPPConnection, if
one still exists, within the lambda.
Fixes SMACK-926.
Reported-by: Damian Minkov <damencho@jitsi.org>
Presence interceptors where hooked into stanza sending listeners,
which are called *after* the stanza has been put on the wire, i.e., to
late for interceptors that any modifications, they may perform, to
take effect.
Fixes SMACK-925.
We now also dynamically add the MUC's main presence interceptor to the
connection.
Reported-by: Damian Minkov <damencho@jitsi.org>
Using any of the two methods is error prone, see 0e0c0a4093 ("[tcp]
Fix handling in connection exceptions when resuming a stream"), as one
can easily forget to check for connection exceptions after it
returned. There are also no longer any call sites of those methods.
Let's inline both variants of this method.
Smack would previous run into "assert smResumptionFailed != null;" at
line 407, since if a connection exception was encountered,
waitForConditionOrConnectionException() would return, but we afterards
just assumed that either SM resumption was successful or not.
Bye Bye changelog.html. You have served us good old friend. But JIRA
does no longer create compatible HTML changelogs. And markdown seems
to be the better alternative anyway.
Smack historically provided fine-grained options for the
SSLContext. This is however not flexible enough, as an option to
specifiy the KeyManager(s) was missing.
This deprecated the options for keystore path, keystore type, and
PKCS#11 library, in favor of an option to set the KeyManager, which
could be aware of the keystore path and type, and the PKCS#11
library. At some point, Smack may provide some high-level methods to
create a KeyManager from provided keystore path, keytsore type and
PKCS#11 library.
Previously, if a SmackFuture both was successful and unsuccessful, it
was possible that the onSuccess() callback was invoked twice.
Reported-by: Boris Grozev <boris@jitsi.org>
