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
Eventually JingleTransportManager should be a subclass of Manager (or
be replaced by Manager), as JingleTransportManager holds a strong
reference to the XMPPConnection. This could cause memory leaks. But
for now, we mimic the Manager API in JingleTransportManger to make a
future transition to Manager easier.
This allows to avoid redundant XML namespaces within IQs, like for
example here:
<iq xmlns='jabber:client' id='EKP8I-1' type='set'>
<jingle xmlns='urn:xmpp:jingle:1' action='content-accept' sid='MySession'>
<content xmlns='urn:xmpp:jingle:1' creator='initiator' name='Hello world'>
</content>
</jingle>
</iq>
Fixes SMACK-917
Reported-by: Jonathan Lennox
Calling userHasLeft before sending the leave presence may result in
invalid state as the MUC presence lister may modify the MUCs local
state, e.g., occupantsMap, conurrently with the leave operation.
If we reset it after the leave presence was send and acknowledged,
then this can not happen as the server will not longer send any MUC
related presences to us.
Also fixes SMACK-914. In theory 52a49769f9 ("[muc] Check for
self-presence first in presence listener") alone would fix SMACK-914,
but this also fixes it indepentendly of 52a49769f9. Both commits are
sensible, so both are applied.
In 9352225f44 ("Rework SOCKS5 unit tests so that they can be run in
parallel") the call to getSocks5Proxy() in
Socks5BytestreamManager.getLocalStreamHost() was removed. Since
getSocks5Proxy() does also start the local proxy, if it is not already
running, this caused Smack to no longer automatically start the local
proxy.
This commit re-adds the call to getSocks5Proxy() and fixes SMACK-912.
Error IQ respones may not contain a data form, e.g.
<iq type="error" id="6LXNC-48" from="pubsub.openfire.xmpp.test" to="anno@openfire.xmpp.test/5dsi4g084a">
<pubsub xmlns="http://jabber.org/protocol/pubsub#owner">
<configure node="fdp/submitted/spot_report"/>
</pubsub>
<error code="403" type="auth">
<forbidden xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</iq>
Also FormNode's toXML() already handled the case where submitForm was
'null'. Only the constructor threw a IAE if submitForm was 'null'.
Fixes SMACK-910.
Closes: https://github.com/igniterealtime/Smack/pull/471
XmlPullParser.getName() only returns a result if the current parser
event is START_ELEMENT or END_ELEMENT. If this is not the case, then
the method may throw (if StAX is used).
The arguments 'to', 'cc, and 'bcc' may be null, hence ensure that they
are non-null when calling e.g. size() on them.
Fixes SMACK-907
Fixes: df96c57093 ("[address] Get rid of PacketCopy workaround")
If the resource of the updated presence is equal to the currently
locked resource, then no further action is required.
Thanks to Pedro Oliveira for reporting this.
Reported-by: Pedro Oliveira <kanytu@gmail.com>
FileTransfer would previously not change the status, even though an
exception has been set, leading users to believe that the transfer is
still ongoing, when it is not.
Some methods of OutgoingFileTransfer take already the
NegotiationProgress callback as argument, some do not. The API is not
ideal, and adding a setter for the callback at least makes it possible
to always have the callback.
The FillableForm API is the most convenient way of filling out a
form. Currently only forms with a FORM_TYPE can be filled, due to a
restriction in FillableForm. This makes filling out untyped forms very
cumbersome.
This commit removes the required FORM_TYPE when using FilledForm (and
therefor FillableForm). Some subclasses of FilledForm already check
that the correct FORM_TYPE is set using FilledForm#ensureFormType().
