The test that's modified in this commit asserts that upon MUC join, stanzas are received in a particular order.
The previous implementation depended on several event listeners (one for presence, one for messages) that did not always fire in the same order in which the corresponding stanzas arrived. This made the approach unsuitable to reliably test the order in which stanzas arrive.
This commit stops using Smack's MUC API when trying to collect the order in which stanzas arrive. Instead, it joins a chatroom and listens for its stanzas using basic stanza handling. As this uses exactly one stanza listener, that's guaranteed to be invoked in order of stanza arrival, any synchronicity issue in the previous implementation no longer applies.
XEP-0115 defines that any dataforms in the disco#info stanza is
ordered prior to the computation of the verification string. This
commit adds a test that verifies that this is done by Smack.
See SMACK-944.
MUC mediated invitations usually have the form
<message
from='coven@chat.shakespeare.lit'
id='nzd143v8'
to='hecate@shakespeare.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite from='crone1@shakespeare.lit/desktop'>
<reason>
Hey Hecate, this is the place for all good witches!
</reason>
</invite>
<password>cauldronburn</password>
</x>
</message>
(source: XEP-0045 Example 57.)
However, previous versions of XEP-0045 specified an additional <x
xmlns='jabber❌conference'> element to be included (see
implementation note in XEP-0045). Therefore, a legacy implementation
may emit a mediated invitations in the form of
<message
from="smack-inttest-mediated-invite-from-8ta77-hw9igz@conference.example.org"
to="smack-inttest-two-8ta77@example.org">
<x xmlns="http://jabber.org/protocol/muc#user">
<invite from="smack-inttest-one-8ta77@example.org"/>
</x>
<x xmlns="jabber❌conference" jid="smack-inttest-mediated-invite-from-8ta77-hw9igz@conference.example.org"/>
</message>
Unfortunately, this matches
MultiUserChatManager.DIRECT_INVITATION_FILTER because
GroupChatInvitation matches <x xmlns="jabber❌conference"/>. However
the message is not a direct invitation but a mediated one. Besides
this invoking the wrong listeners (direct vs. medidated) the value for
'inviter' that's used to invoke that listener will be false.
To fix this, extend DIRECT_INVITATION_FILTER with
NotFilter.of(MUCUser.class) to avoid matching those legacy mediated
invitations.
Fixes SMACK-943
Co-authored-by: Florian Schmaus <flo@geekplace.eu>
Making use of the new assertion handling for MultiResultSyncPoint, the integration test that uses that implementation can now get improved assertion messages. This will allow users to more quickly determine why a test is failing.
When occupant One waits for occupant Two to join the room, One should register the corresponding listener _before_ Two joins.
Without this, a race conditions occurs, where Two could have joined the room before One registered the listener, thus missing the event.
The test was originally implemented when version 1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.3.0.
The test was originally implemented after the most current version of the XEP was published, making it plausible that this implementation matches the current version of the XEP: 0.3.
The test was originally implemented when version 1.15.7 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications (with regards to the functionality that is the subject of the tests), making it plausible that this implementation matches the current version of the XEP: 1.26.0.
The test was originally implemented when version 2.0 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 2.0.1.
The test was originally implemented when version 0.1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.2.0.
These tests were originally implemented when versions 0.2.1 and 0.3.0 of the XEP were the most current version. Later versions of the XEP do significantly modify the specifications, making it plausible that this implementation matches the version of the XEP that was the most recent version at the time the test was created: 0.3.0
The test was originally implemented when version 1.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.2.
The test was originally implemented when version 1.25 of the XEP was the most current version. Later versions of the XEP do significantly modify the specifications, but the test implementation has had continuous changes over time too. This makes it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.2.1
The test was originally implemented when version 0.5.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.6, making it plausible that this implementation matches the version of the XEP, followed by some editorial changes: 0.6.3 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.1.
The test was implemented when version 0.4 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.5.1.
The test was implemented when version 0.3.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.4.0, making it plausible that this implementation matches that version of the XEP: 0.4.0 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.9.
The test was implemented when version 1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.3.1.
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.3.0.
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 2.1.
The test was implemented when version 1.5.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.6.0.
An optional configuration option for the Smack Integration Test framework has been added that allows one to bypass DNS when resolving a host for the XMPP domain that is the subject of the test.
The `host` option can be used with IP addresses (eg: `-Dsinttest.host=127.0.0.1`) and DNS names (eg: `-Dsinttest.host=example.org`).
When Smack requests a subject change of a MUC, an error returned by
the server (eg: 'forbidden') should be propagated (as suggested by the
pre-existing javadoc).
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
Instead of Stanza, use StanzaView as constructor parameter type of
StanzaIdFilter. Even though StanzaView also includes builders, the
Stanza ID is even immutable in builders.
This tests reliably fails, not only for me. I suspect that it is
related to the order of events checked by this tests, that can not be
reliably tested, even with sync listeners.
It is also is primarily a test for server behavior.
