With 92f253cc74 ("[core] Replace
AbstractXMPPConnection.inOrderListeners") we changes the behavior of
listeners. This commit documents the expectations to the user.
Also delete StanzaIdTest since the test was fundamentally weak and
flawed. It does not work anyway, since TestIQ has a fixed stanza ID.
Fixes SMACK-931.
Set started with Smack 4.4 to set myRoomJid to null, introduced by
ab2822be3e ("muc: also set myRoomJid to null if we have left the
room"), however the code comment still states that we "do not reset
nickname here" (and myRoomJid contains the nickname as its
resourcepart).
Reported-by: Damian Minkov <damencho@jitsi.org>
On dinamically remove the last existed presence interceptor
we also should to remove the MUC's main presence interceptor from the connection.
Fixes: 60fee7b ("[muc] Fix Presence interceptors")
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>
