This reverts commit d217c32e72.
Since the new error prone version requires Java 17, we can also use
the bnd gradle plugin version that requires Java 17.
Bump Gradle from 6.8.3 to 8.10.2 and increase the minimum required
Java version from 8 to 11 (SMACK-953).
The switch from Java 8 to 11 caused some Bytecode portability issues
regarding NIO Buffers. Java changed with version 9 the return type of
some subclasses of Buffer to return the specific Buffer type instead
of the Buffer superclass [JDK-4774077]. For example, ByteBuffer.filp()
previously returned Buffer, while it does return ByteBuffer now.
This sensible change was not reflected by the Android API [1], which
means that AnimalSniffer rightfully started to complain that there is
no method "ByteBuffer ByteBuffer.flip()" in Android, there is only
"Buffer ByteBuffer.flip()", and those are incompatible methods on
Java's Bytecode layer.
As workaround, this changes
return charBuffer.flip().toString();
to
((java.nio.Buffer) charBuffer).flip();
return charBuffer.toString();
to restore the Bytecode portability between Android and Java.
Errorprone also got new checks, of which JavaUtilDate and JdkObsolete
are wroth mentioning.
JavaUtilData basically strongly recommends to use Java's newer time
API over java.util.Date. But since Smack was Java 8 until now,
j.u.Date is widely used.
Similar JdkObsolete mentions obsolete JDK APIs, like data structures
like Vector and Stack. But mostly LinkedList, which should usually be
replaced by ArrayList. And this is what this commit largely does.
JDK-4774077: https://bugs.openjdk.org/browse/JDK-4774077
1: https://issuetracker.google.com/issues/369219141
Due to a change in Smack 4.5.0-beta2, test execution of (all) SINT tests is aborted when `FormTest` is executed.
It appears that Smack now has more strict argument validation when setting thread IDs on message stanzas. This validation should not fail for the tests that are shipped with Smack.
This is the stack trace when executing the failing test (which no longer occurs after the change in this commit is applied):
```
Exception in thread "main" java.lang.IllegalArgumentException: thread must not be null nor empty
at org.jivesoftware.smack.util.StringUtils.requireNotNullNorEmpty(StringUtils.java:533)
at org.jivesoftware.smack.packet.Message$Thread.<init>(Message.java:326)
at org.jivesoftware.smack.packet.MessageBuilder.setThread(MessageBuilder.java:70)
at org.jivesoftware.smack.packet.MessageBuilder.setThread(MessageBuilder.java:66)
at org.jivesoftware.smackx.xdata.FormTest.testFilloutForm(FormTest.java:133)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.lambda$runTests$0(SmackIntegrationTestFramework.java:476)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runConcreteTest(SmackIntegrationTestFramework.java:556)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework$PreparedTest.run(SmackIntegrationTestFramework.java:764)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runTests(SmackIntegrationTestFramework.java:544)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.run(SmackIntegrationTestFramework.java:277)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.main(SmackIntegrationTestFramework.java:115)
```
After a room is destroyed, the MultiUserChat-stored representation of the 'join' state of any occupant should be updated to reflect that the user is no longer in the room.
This fixes a problem where an occupant (that not itself triggered the destruction) appears to continue be part of a room after its destruction.
Additional integration test assertions are added to check for the invalid state fixed by this commit.
fixes SMACK-949
Only list-multi and list-single fields require at least one value when
submitting a form. In other cases, for example XEP-0045's
muc#roomconfig_roomadmins, which is of type jid-multi, is used without
any values to reset the room's admins list.
Fixes SMACK-946.
The getRegistrationInfo() returns a registration form that may also contain a CAPTCHA.
We need to get the full Registration object to get the fields.
Also it should be possible to call it multiple times to update the form.
Signed-off-by: Sergey Ponomarev <stokito@gmail.com>
When an occupant gets its membership revoked in an members-only room, the appropriate method of registered ParticipantStatusListeners should be invoked.
After test execution, the OpenPGP for XMPP integration tests should clean up the data published via PEP. This prevents these tests from interfering with other tests.
Additional cleanup of test fixtures:
- various tests that change roster/subscription get a roster-reset
- one test that registers a listener now deregisters that listener
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.
In order to be able to identify potential room leaks, use unique rooms
names for the two integration tests. Also destroy the room in
mucJoinSemiAnonymousRoomReceivedByNonModeratorTest().
Only declare the body of the participant listeners once. And increase
the try block, to account, for example, for
participantOneSeesTwoEnter.waitForResult() throwing.
MUCUser.getStatus() returns a set, checking if a particular MUC status
number is set should be done via a simple and efficient set operation
and not by resorting to using Java's stream API.
This method only had one call site and using such "helper" methods has
the drawback that it is not immediatly obvious what it does when
reading the integration test code. Therefore, we better inline it.
When the incoming unavailable presence is signalling a nickname
change (303), then do not invoke userHasLeft(), because the user
actually does not leave but instead just changes its nickname.
Note that this would also have had fixed SMACK-942, as it would
resolve the deadlock. However, using a dedicated lock for
changeNickname() still seems sensible, and if its just to avoid a bit
of lock contention.
What this also fixes is that a MultiUserChat does no longer invoke its
listener-based callbacks after a nickname change, as previously, after
a nickname change, the userHasLeft() would have been invoked, which
tears down the listeners. This issue was found with
MultiUserChatOccupantIntegrationTest.mucChangeNicknameInformationTest().
Using this method used to result in a deadlock, as shown by these two threads
"main" #1 prio=5 os_prio=0 cpu=926.39ms elapsed=21.00s tid=0x00007f463802c800 nid=0x5a691 in Object.wait() [0x00007f463f323000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.23/Native Method)
- waiting on <0x0000000622e82fd8> (a org.jivesoftware.smack.StanzaCollector)
at org.jivesoftware.smack.StanzaCollector.nextResult(StanzaCollector.java:206)
- waiting to re-lock in wait() <0x0000000622e82fd8> (a org.jivesoftware.smack.StanzaCollector)
at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:270)
at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:228)
at org.jivesoftware.smackx.muc.MultiUserChat.changeNickname(MultiUserChat.java:1314)
- locked <0x0000000622e19700> (a org.jivesoftware.smackx.muc.MultiUserChat)
at org.jivesoftware.smackx.muc.MultiUserChatOccupantIntegrationTest.mucChangeNicknameInformationTest(MultiUserChatOccupantIntegrationTest.java:981)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.23/Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.23/NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.23/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.23/Method.java:566)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.lambda$runTests$0(SmackIntegrationTestFramework.java:476)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework$$Lambda$141/0x000000084026e040.execute(Unknown Source)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runConcreteTest(SmackIntegrationTestFramework.java:551)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework$PreparedTest.run(SmackIntegrationTestFramework.java:759)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runTests(SmackIntegrationTestFramework.java:539)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.run(SmackIntegrationTestFramework.java:277)
- locked <0x000000062d191318> (a org.igniterealtime.smack.inttest.SmackIntegrationTestFramework)
at
org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.main(SmackIntegrationTestFramework.java:115)
"Smack Cached Executor" #19 daemon prio=5 os_prio=0 cpu=7.85ms elapsed=20.48s tid=0x00007f4638a42800 nid=0x5a6b2 waiting for monitor entry [0x00007f46023fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jivesoftware.smackx.muc.MultiUserChat.userHasLeft(MultiUserChat.java:2281)
- waiting to lock <0x0000000622e19700> (a org.jivesoftware.smackx.muc.MultiUserChat)
at org.jivesoftware.smackx.muc.MultiUserChat.access$800(MultiUserChat.java:117)
at org.jivesoftware.smackx.muc.MultiUserChat$3.processStanza(MultiUserChat.java:263)
at org.jivesoftware.smack.AbstractXMPPConnection.lambda$invokeStanzaCollectorsAndNotifyRecvListeners$8(AbstractXMPPConnection.java:1654)
at org.jivesoftware.smack.AbstractXMPPConnection$$Lambda$127/0x000000084022f440.run(Unknown Source)
at org.jivesoftware.smack.AbstractXMPPConnection$10.run(AbstractXMPPConnection.java:2213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.23/ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.23/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.23/Thread.java:829)
The changeNickname() method was synchronized and is userHasLeft(),
this caused a deadlock since changeNickname() awaits the presence that
is send as result of the nickname change. But this presence is also
processed in a listener which invokes userHasLeft(). However, this
invocation blocks as userHasLeft() is waiting on the montior currently
hold by the thread invoking changeNickname().
To fix this, we change changeNickname() to not take the MultiUserChat
monitor, but instead use a dedicate lock.
Fixes SMACK-942.
When comparing SINT-configuration to annotations, a bit of normalization occurs, to ensure that common variations in denoting a specification are detected to be equal to each-other.
The dash (`-`) character is commonly used when referencing a specification (eg: `XEP-0001`).
This commit ensures that usage of a dash (`-`) character is included in the normalization process, making `XEP 0001`, `XEP0001` and `XEP-0001` all to be identified as the same reference.
Some specifications are versioned. XEPs, for example, typically are. It is useful to annotate an implementation with the specific version of the specification that is being tested.
The default set of packages that is scanned for integration tests are referencing jivesoftware. This commit adds igniterealtime-oriented package names.
The implementation of the test that is being removed depends on a server
characteristic that will cause a loop of presence stanzas (which obviously is
bad). A RFC3921-compliant client can send an 'acknowledgement' after receiving
a presence 'subscribed' stanza, in the form of a presence 'subscribe' stanza.
See section 8.2 of RFC3921.
When a server implementation does not ignore this acknowledgement, the domain
of the recipient MUST (RFC6121 section 3.1.3) respond with a 'subscribed' on
behalf of the recipient (which is what the now removed test was verifying).
This can trigger the RFC3921-compliant sender to again receive 'subscribed',
that it again can acknowledge, which causes a loop.
To test RFC6121, the subscription state of the recipient must somehow be
modified to reflect a different state than that of the initiator. I'm not sure
if that is feasible with the SINT framework.
`AbstractSmackIntTest#assertResult()` takes an argument that is an assertion message. When the sync point times out, that message should be logged.
The following illustrates the change, as a result of this assertion failing:
```
assertResult(resultSyncPoint, "Expected " + conTwo.getUser() + " to receive message that was sent by " + conOne.getUser() + " in room " + mucAddress + " (but it did not).");
```
Prior to this change, this is logged:
```
SEVERE: MultiUserChatIntegrationTest.mucTest (Normal) failed: java.util.concurrent.TimeoutException: Timeout expired
java.util.concurrent.TimeoutException: Timeout expired
at org.igniterealtime.smack.inttest.util.ResultSyncPoint.waitForResult(ResultSyncPoint.java:49)
at org.igniterealtime.smack.inttest.AbstractSmackIntTest.assertResult(AbstractSmackIntTest.java:104)
at org.igniterealtime.smack.inttest.AbstractSmackIntTest.assertResult(AbstractSmackIntTest.java:99)
at org.jivesoftware.smackx.muc.MultiUserChatIntegrationTest.mucTest(MultiUserChatIntegrationTest.java:132)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
(snip)
```
With the change in this commit, that becomes:
```
SEVERE: MultiUserChatIntegrationTest.mucTest (Normal) failed: java.util.concurrent.TimeoutException: Expected smack-inttest-two-jskr4@example.org/two-jskr4 to receive message that was sent by smack-inttest-one-jskr4@example.org/one-jskr4 in room smack-inttest-message-jskr4-aud43i@conference.example.org (but it did not).
java.util.concurrent.TimeoutException: Expected smack-inttest-two-jskr4@example.org/two-jskr4 to receive message that was sent by smack-inttest-one-jskr4@example.org/one-jskr4 in room smack-inttest-message-jskr4-aud43i@conference.example.org (but it did not).
at org.igniterealtime.smack.inttest.util.ResultSyncPoint.waitForResult(ResultSyncPoint.java:53)
at org.igniterealtime.smack.inttest.AbstractSmackIntTest.assertResult(AbstractSmackIntTest.java:104)
at org.igniterealtime.smack.inttest.AbstractSmackIntTest.assertResult(AbstractSmackIntTest.java:99)
at org.jivesoftware.smackx.muc.MultiUserChatIntegrationTest.mucTest(MultiUserChatIntegrationTest.java:132)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
(snip)
```
This adds a new configuration option, `testRunResultProcessors`, that allows a user to customize the way the results of a test run is processed.
By default, the pre-exising printing-to-stderr is used.
When refactoring the original implementation, this annotation was expected to be present on methods. It later was changed to be a type-based annotation. This particular usage of the annotation was not properly modified to account for that change.
When testing for default role assignment based on affiliation, depending on the 'adminGranted' callback is dangerous, as this callback appears to be only invoked when the affected occupant has already joined the room.
The exact occupant count isn't something that these tests need to assert either.
This commit changes the test implementations to proceed when all expected occupants have been detected by the user performing the change.
These changes combined intend to make the tests more robust, with regards to the order in which several events are fired (which might be unexpeced, given threading implementation in server (clusters) and Smack stanza handling.
When using 'assertEquals', the first argument is to be the _expected_ value, the second the _actual_ value. When this is inverted, the functional test will still succeed, but any generated error message ("Expected X, got Y") will be wrong.
This commit fixes the order of arguments, mostly in the sinttest module.
This adds human-readable text to nearly all assertions in SINT. It is intended that these, together with an XMPP dump of the traffic that was exchanged during the test, allows an observer to have a chance to determine why a particular test failed, without analyzing the test code itself.
A new annotation is introduced (`SpecificationReference`) that can be used to annotate a SINT test class
The properties are available in the annotation:
- `document`: Identifier for a specification document, such as 'RFC 6120' or 'XEP-0485'
The pre-existing `SmackIntegrationTest` annotation has now received two new properties:
- `section`: Identifier for a section (or paragraph), such as '6.2.1'
- `quote`: A quotation of relevant text from the section
These are expected to be used in context of the `SpecificationReference` annotation.
The SINT execution framework is modified so that two new configuration options are available:
- `enabledSpecifications`
- `disabledSpecifications`
These operate on the value of the `document` property of the annotation. Their usage is comparable
to that of the pre-existing `enabledTests` and `disabledTest` configuration options.
Execution output now includes the document, section and quote that's on the annotated test, when
the test fails. This allows an end-user to easily correspond a test failure with a particular
specification.
Calling write() in FillableForm's constructor causes a NPE because
write() makes use of requiredFields which has not been set at this
time. Furthermore, write() makes use of missingRequiredFields, which
is also populated in that loop. Therefore, we have to delay the
invocation of write() until requiredFields got set.
Thanks to Dan Caseley for reporting this.
Reported-by: Dan Caseley <dan@caseley.me.uk>
Calling write() in FillableForm's constructor causes a NPE because
write() makes use of requiredFields which has not been set at this
time. Furthermore, write() makes use of missingRequiredFields, which
is also populated in that loop. Therefore, we have to delay the
invocation of write() until requiredFields got set.
Thanks to Dan Caseley for reporting this.
Reported-by: Dan Caseley <dan@caseley.me.uk>
[SMACK-941](https://igniterealtime.atlassian.net/browse/SMACK-941) Suppress "roster not loaded while processing presence" warning if its caused by the reflected self-presence
### Bug
[SMACK-938](https://igniterealtime.atlassian.net/browse/SMACK-938) Busy loop in SmackReactor
[SMACK-940](https://igniterealtime.atlassian.net/browse/SMACK-940) Ignore IPv6 Zone IDs in incoming streamhost candidates