This is a follow-up on 198c51356d ("Add initial support for XEP-0103
and XEP-0104: URL Address Information"), which
1. adds the entries to the support XEPs table
2. registers the provider
3. renames the package from url_address_information to urldata (aka.
the shortname of XEP-0130).
The default local address is often just "the first address found in the list of addresses read from the OS" and this might mean an internal IP address that cannot reach external servers. So wherever possible use the same IP address being used to connect to the XMPP server because this local address has a better chance of being suitable.
This MR adds the above behaviour, and two UTs to test that we use the local XMPP connection IP when connected, and the previous behaviour when not.
Exposes a method for a MUC to invite a user to the room, and adds a listener to the MultiUserChat listener to inform users of direct invitations they have received.
Fixes SMACK-932.
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.
While markdown is easier to write, Smack's markdown documentation was
never tightly coupled with the source. For example, the markdown
documentation never provided links to the actual Java classes and
methods. This poses the risk that the documentation and the code
diverge over time. Furthermore, javadoc is constantly improving (for
example @snippet annotations) and I expect that one will be able to
write javadoc in markdown.
Fixes SMACK-928.
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")
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>
This method is meant to provide 'raw' access to what has been sent
over the wire. It is assumed to be not of much use in the typically
case, but provided for completeness.
According to XEP-0004 § 3.3, the default value of a boolean form field
is 'false'. And since users are typically interested in getting the
value, and not potentially 'null' as result, we adjust the behavior of
the getValueAsBoolean() method consider the default value.
Since notify() is a rather expensive operation, we should only invoke
it once. Especially since some servers include 110 in all self
presences, not just the initially reflected one on MUC join.
The change in 52a49769f9 ("[muc] Check for self-presence first in
presence listener") caused all self-presences (MUC user status 110) to
be ignored in the further processing chain eventually invoking
checkRoleModifications() and checkAffiliationModifications(). However,
some servers (e.g., ejabberd) include 110 not only in the initial
presence but in all following, and we ant to process these.
Fixes SMACK-918
Fixes: 52a49769f9
