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>
This is a follow-up commit after 441d677644 ("Initial support for
XEP-0446: File Metadata Element"). It includes the following changes
1. Use idiomatic provider design for FileMetadataElementProvider
2. Add XEP-0264 and XEP-0446 to the list of supported XEPs (both where
added with441d6776447f)
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).
Using 60 seconds makes it sometimes easy to miss that the some action
was 1 minute after the timeout, because only a single digit in the
timestamp changes. Using a prime number as timeout makes this more
obvious.
For certain use cases, this provides a performance improvement,
probably due better cache locality. However, it comes with the cost of
additional memory consumption.
This was initially suggested by Boris Grozev, who also reported a
significant performance problem of
XmlStringBuilder/LazyStringBuilder. However, the main cause of the
performance probelm was the missing caching of LazyStringBuilder. The
length of the lazy string is now cached by LazyStringBuidler since
70e48300a6 ("[core] Cache length in LazyStringBuilder"), which
accounts for large performance improvement. A significantly smaller
improvement is achieved by this commit and setting
XmlStringBuilder.FLAT_APPEND to 'true'.
Suggested-by: Boris Grozev <boris@jitsi.org>
When performing IBR-based account registration, we do not need to
login nor are the admin credentials typically available.
Suggested-by: Guus der Kinderen <guus@goodbytes.nl>
With 92f253cc74 ("[core] Replace
AbstractXMPPConnection.inOrderListeners") we changes the behavior of
listeners. This commit documents the expectations to the user.
Prior to this fix, Smack requires the 'open' element send on a websocket connection to be collapsed. With the change in
this commit, an expanded (eg: `<open ...></open>`) element can also be used.
fixes SMACK-935
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.
Subclasses of AbstractSmackSpecificLowLevelIntegrationTest have test
methods with no parameters. This was, after the refactoring in
c5bb15c631 ("[sinttest] Add UnconnectedConnectionSource for
low-level tests") not handled properly.
Fixes: c5bb15c631 ("[sinttest] Add UnconnectedConnectionSource for low-level tests")
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.
Guus reports the following infinite recursing causing a
StackOverflowError:
Exception in thread "main" java.lang.StackOverflowError
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:142)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraphInternal(ModularXmppClientToServerConnection.java:399)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraph(ModularXmppClientToServerConnection.java:339)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.shutdown(ModularXmppClientToServerConnection.java:551)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.instantShutdown(ModularXmppClientToServerConnection.java:530)
at org.jivesoftware.smack.AbstractXMPPConnection.notifyConnectionError(AbstractXMPPConnection.java:1024)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.access$100(ModularXmppClientToServerConnection.java:134)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$1.notifyConnectionError(ModularXmppClientToServerConnection.java:185)
at org.jivesoftware.smack.websocket.impl.AbstractWebSocket.onWebSocketFailure(AbstractWebSocket.java:128)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.onWebSocketFailure(Java11WebSocket.java:162)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:146)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
...
This is because sendClose() in Java11WebSocket.disconnect() throws,
potentially because the output stream is already closed. We previously
would feed the exception into the onWebSocketFailure(Exception)
machinery, which would then again attempt a disconnect.
Since a failed sendClose() is nothing that needs special handling, we
simply log the exception as error. Furthermore, we only issue
sendClose() if the WebSocket's output is still open, i.e., if there is
a chance that it actually works.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
Previously low-level tests where run, potentially multiple times, with
the default connection descriptor.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
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.
When enabled, the websocket implementation will attempt to use two implicit endpoints, using these URLs:
- `wss://[host]:5443/ws`
- `ws://[host]:5443/ws`
These endpoints should include ports that are used by default by known implementations, such as 5280/5281 (Prosody) and 7070/7443 (Openfire).
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")
I am not happy with the concept of a build system wrapper, not to say
that I despise it. There is no reason why a single machine couldn't
have multiple versions of a build system-wide installed, and there is
no reason why each developer should download an individual copy of a
build system into the developers home directory. But here we are…
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>
All other enum-using methods of XmlStringBuilder already use
Enum.toString(), as opposed to Enum.name(), this was the only left. I
do not remember why I did not to change this method too, probably
because of its plenty call sites.
But since this method already broke Jingle XML serializaton,
JingleAction was e.g., 'session_accept' when it should be
'session-accept', we change it now.
Fixes SMACK-921.
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.
When using the Enhanced Debugger, a UI application is very noticably slow, especially around establishing a new
session. Profiling shows that much of the overhead is caused by XMPP-data being added to the text areas that are
on the "raw sent packets" and "raw received packets" tabs of the debugger.
This commit improves performance (considerably) by:
- properly limiting the amount of lines in those text areas (this was intended but broken in the old implementation)
- buffering data to be added in batches, to reduce the amount of invocations to JTextChat.append()
As an aside: some newline-based formatting was removed. As the provided data is now already formatted, retaining that
did not make much sense anymore.
Similar fix as 9b339efbc1 ("Prevent password enforcement for SASL
anonymous") just for SASL GSSAPI. Fixes SMACK-920.
Fixes: 92f4aadfdc ("[sasl] Avoid mechanisms that need a password when none is available")
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
The UserTuneIntegrationTest, in rapid succession:
- add a listener for PEP-published usertune data
- publishes a usertune
- waits for a notification to arrive
Implicit to adding the listener is the publication of a change in
Pubsub notification filtering. This can involve a stanza handshake,
as CAPS is involved.
A race condition exists where the usertune data can be published
before the notification filter has been properly applied.
The changes in this commit add a synchronzation point that ensures
that the notification filter is in place, before the usertune data
is published.
Co-authored-by: Paul Schaub <vanitasvitae@fsfe.org>
Connections like XMPPTCPConnection may still reported connected, if
they are, for example disconnected but resumable. This is already
accounted for in throwAlreadyConnectedExceptionIfAppropriate(), hence
the assert is unnecessary and leads to false negatives for
XMPPTCPConnection.
For the sake of completeness, the right condition, assuming
XMPPTCPConnection is used, for the assert would be:
assert !connected || disconnectedButResumable;
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
AbstractXMPPConnection waits for the flag lastFeaturesReceived since
57961a8cc1, but it is never set from
BOSH connections. Use parseFeaturesAndNotify instead of
parseFeatures to set the signal.
Similarly the XmlEnvironment is not set from bosh, but required in
ParserUtils.getXmlLang.
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.
The assert statement in CarbonManager's connectionClosed() connection
listener callback was erroneous. A connection may be connected, but
never was authenticated. If now the connection is closed, then
carbonsListener was never setup (via the authenticated() callback),
causing the assert to throw an exception.
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.
Parsers handed over to IQ providers should be positioned at the IQ
child element when being invoked. Therefore we remove the wrapping
<iq> in some test XML.
Also make checkMamPrefsIQProvider() a paramterized test.
This also fixes a errornous merge where the same branch with different
commit was merged into master and 4.4
The conflicting commits are
4.4:
8f760eaeb3 getRawValueCharSequences
e626580f68
master:
b47225c2c1 getRawValues
097d245358
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
If the successor's module is disabled then the vertex may be null. In
this case, we can simple continue with the next successor in the list.
Previously, due to d33a5a23c3 ("[core] Introduce
Builder.failOnUnknownStates() and unit tests") this would trigger an
assert in addOutgoingEdge().
Fixes: d33a5a23c3 ("[core] Introduce Builder.failOnUnknownStates() and unit tests")
The previous approach of emitting a severe log message when a
state (descriptor) was unknown was misleading. There are valid cases
where some states are not known, if, for example, a module was
explicitly disabled.
Using Builder.failOnUnknownStates() in unit tests is far cleaner, as
the existence of unknown states is tested in a controlled environment:
one where are states are supposed to be known.
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).
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).
Some roster-based tests depend on there not being any prior subscription state beteween entities. The utility method that
tries to guarantee that, acts on the state of the roster that's cached in memory, but acts on the one that's stored on the
server. This occasionally causes issues, as both representations might be different.
Stability is added in this commit by:
- refreshing the roster from the server prior to evaluating it
- ignoring an 'item-not-found' as returned by the server, when the code tries to remove that item.
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")
Refactored using
find . -type f -name "*.java" |\
xargs sed -i -E |\
's/\.createStanzaCollectorAndSend\((\w+)\)\.nextResultOrThrow\(\);/.sendIqRequestAndWaitForResponse(\1);/'
and some manual refactoring.
If something goes wrong when destroying a MUC, we want to be notified
about it immediately, as further results of the integration test run
are unreliable anyway.
ExtensionElement is now a marker interface that requires all
implementation non-abstract classes to carry a static final QNAME
field (of type QName). This is verified by a new unit test.
Also FullyQualifiedElement is renamed to simply XmlElement. XmlElement
is used over ExtensionElement when implementing classes do not
statically know the qualified name of the XML elements they
represent. In general, XmlElement should be used sparingly, and every
XML element should be modeled by its own Java class (implementing
ExtensionElement).
Properly reply to IQ requests with feature-not-implemented or
service-unavailable. In case there is no IQ request handler but the IQ
namespace is known, we reply with feature-not-implemented, otherwise
with service-unavailable.
The MAM integration test setup attepts to set MAM preferences (XEP-0441).
When a server does not support this XEP, the setup phase errors out, preventing
the tests from being executed.
There is no functional reason why tests shouldn't be run when XEP-0441 is not
supported: the tests can run against the default configuration of the MAM
service.
This commit ignores feature-not-implemented errors when MAM
preferences are set.
[Ignore only feature-not-implemented errors, log ignored errors)
Modified-by: Florian Schmaus <flo@geekplace.eu>
Appearently simply calling ClassLoader.getSystemResourceAsStream()
works on Java SE but not on Android. But our FileUtils are able to
load the resource stream on Android.
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>
If we do not create the fromMarkers initialized with 'false' at the
start, then it may appear like all messages are received, because we
only check for false markers. But if there is not even the fromMarkers
array, then we do not see those 'false' markers.
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.
OmemoAesCipher is the sole point where OMEMO related AES operations
are performed. This allows OmemoAesCipher to check in a static block
if AES is available. If AES is not available it throws a (hopefully)
helpfull exception message.
Typically AES is not available on Android if no security provider
providing AES, like Bouncy Castle, has been explicitly configured.
If we do not ignore the exception, then users may receive an exception
via connectionClosedOnError() on connection termination. Those
exceptions are typically unwanted if they are caused e.g. because the
server does not send a closing stream tag.
We previously ignored exceptions in this case already, but that
behavior was changed with [1: 57961a8cc1]. This commit re-adds the
behavior.
1: 57961a8cc1
Remove SynchronizationPoint
StAX's NamespaceContext.getNamespaceURI(String) is allowed to throw an
IllegalArgumentException in case the argument is null. We simply
re-use getNamespace(String) which will substitute the default
namespace if the argument is null to avoid this.
Connection closed due to an exception
java.lang.IllegalArgumentException: Illegal to pass null as argument
at com.ctc.wstx.sr.NsInputElementStack.getNamespaceURI(NsInputElementStack.java:486)
at org.jivesoftware.smack.xml.stax.StaxXmlPullParser.getNamespace(StaxXmlPullParser.java:113)
at org.jivesoftware.smack.AbstractXMPPConnection.parseFeatures(AbstractXMPPConnection.java:1852)
at org.jivesoftware.smack.AbstractXMPPConnection.parseFeaturesAndNotify(AbstractXMPPConnection.java:1887)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1300(XMPPTCPConnection.java:130)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:983)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936)
at java.lang.Thread.run(Thread.java:748)
Fixes SMACK-903
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().
This also lifts a bunch of logic from smack-websocket-okhttp into
smack-websocket. Furthermore, the following subprojects require now
Java 11:
- smack-integration-test
- smack-omemo-signal-integration-test
- smack-repl
- smack-websocket-java11
Related tracking issue: SMACK-835
This also means that smack-integration-test needs to declare a
dependency on Guava, which was previously available as transitive
dependency of 'reflections' 0.9.11.
This also resulted in a refactoring of the Providers and parsing
Exceptions. NumberFormatException and ParseException can now be thrown
directly, the wrapping in a SmackParsingException is down at a higher
layer, i.e. in AbstractProvider.
Assume the element
<foo:bar xmlns='namespace' xmlns:foo='foo-namespace'/>
then the <bar/> element's namespace is 'foo-namespace', but the
default namespace is 'namespace'. And this is the namespace that
scopes into inner elements.
aTalk shows the following exception:
2020-12-14 12:11:13.704 7370-30976/org.atalk.android E/AndroidRuntime: FATAL EXCEPTION: AccountManager.loadStoredAccounts
Process: org.atalk.android, PID: 7370
java.lang.AssertionError: Element type 'EE' is neither of type Class or ParameterizedType
at org.jivesoftware.smack.provider.AbstractProvider.<init>(AbstractProvider.java:46)
at org.jivesoftware.smack.provider.Provider.<init>(Provider.java:40)
at org.jivesoftware.smack.provider.ExtensionElementProvider.<init>(ExtensionElementProvider.java:29)
at org.xmpp.extensions.DefaultExtensionElementProvider.<init>(DefaultExtensionElementProvider.java:43)
at org.xmpp.extensions.coin.CoinIQProvider.<init>(CoinIQProvider.java:46)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initialize(ProtocolProviderServiceJabberImpl.java:2091)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.createService(ProtocolProviderFactoryJabberImpl.java:121)
at net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:934)
at net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:139)
at net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:294)
at net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:394)
at net.java.sip.communicator.service.protocol.AccountManager.access$000(AccountManager.java:36)
at
net.java.sip.communicator.service.protocol.AccountManager$1.run(AccountManager.java:329)
where CoinIQProvider line 46-47 [1] reads
private final DefaultExtensionElementProvider<URIsExtension> urisProvider
= new
DefaultExtensionElementProvider<>(URIsExtension.class);
This fixes SMACK-898.
1: f61f264312/aTalk/src/main/java/org/xmpp/extensions/coin/CoinIQProvider.java (L47)
The method lookupHostAddress() returns null in case of an error, hence
we need to test if the returned value is null prior adding the endpoint.
Should fix the following NPE:
java.lang.NullPointerException:
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration (XMPPTCPConnection.java:606)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal (XMPPTCPConnection.java:846)
at org.jivesoftware.smack.AbstractXMPPConnection.connect (AbstractXMPPConnection.java:530)
at org.jivesoftware.smack.ReconnectionManager$2.run (ReconnectionManager.java:282)
at java.lang.Thread.run (Thread.java:784)
Reported-by: Eng ChongMeng <cmeng.gm@gmail.com>
This fixes an inconsistent representation of a 'no error' representation, that
causes a file transfer in which not enough bytes were transferred to _not_ be
marked as having a problem.
This prevents a race condition of enter() with the presence listern by
waiting until all presences have been processed.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
To increase readability, and with that maintainability, we rename
'presence' to 'reflectedSelfPresence' in MultiUserChat.enter(), to
make it clear what kind of presence this variable holds.
Also mark the variable as final.
While running the Smack integration tests, a line like this is printed to std-out somewhere
Available tests: 21 (Disabled 12 classes and 6 tests
There's a missing character on the end of that line, which makes the author of this commit twitch.
This commit adds the missing character, resulting in a line like this:
Available tests: 21 (Disabled 12 classes and 6 tests)
Do net put an ack to the queue if it has already been shutdown. Some
servers, like ejabberd, like to request an ack even after we have send
a stream close (and hance the queue was shutdown). If we would not
check here, then the ack would dangle around in the queue, and be send
on the next re-connection attempt even before the stream open.
See the following trace of the MUC bookmarks integration test. The
fact that it is a MUC test does not matter, but this test does
disconnect the connection and reconnect it. Not how the server,
ejabberd in this case, requests an SM ack by sending an <r/> even
though we already send the </stream:stream>:
22:22:05 SENT (4):
<iq id='MD4UC-61' type='set'>
<query xmlns='jabber:iq:private'>
<storage xmlns='storage:bookmarks'>
<conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'>
<nick>
Nick-P2VXD7
</nick>
</conference>
</storage>
</query>
</iq>
22:22:05 RECV (4):
<r xmlns='urn:xmpp:sm:3'/>
22:22:05 SENT (4):
<a xmlns='urn:xmpp:sm:3' h='29'/>
22:22:05 RECV (4):
<message to='sinttest-7in7j-4@salem.geekplace.eu' from='sinttest-7in7j-4@salem.geekplace.eu' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
<conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'>
<nick>
Nick-P2VXD7
</nick>
</conference>
</storage>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address jid='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' type='replyto'/>
</addresses>
</message>
22:22:05 RECV (4):
<iq xml:lang='en-US' to='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' from='sinttest-7in7j-4@salem.geekplace.eu' type='result' id='MD4UC-61'/>
22:22:05 SENT (4):
<presence id='6MS6J-20' type='unavailable'/>
<a xmlns='urn:xmpp:sm:3' h='31'/>
<!-- We have closed the stream -->
</stream:stream>
<!-- But the server still requests an SM ack -->
22:22:05 RECV (4):
<r xmlns='urn:xmpp:sm:3'/>
22:22:05 RECV (4):
</stream:stream>
22:22:05 XMPPConnection closed (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4))
22:22:05 SENT (4):
<a xmlns='urn:xmpp:sm:3' h='31'/>
22:22:05 SENT (4):
<stream:stream xmlns='jabber:client' to='salem.geekplace.eu' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='sinttest-7in7j-4@salem.geekplace.eu' xml:lang='en-US'>
22:22:05 RECV (4): ?xml version='1.0'?>
<stream:stream id='3379123514446782311' ver
22:22:05 RECV (4): sion='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'>
<stream:error>
<invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
22:22:05 XMPPConnection closed due to an exception (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4))
org.jivesoftware.smack.XMPPException$StreamErrorException: invalid-xml You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:981)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936)
at java.base/java.lang.Thread.run(Thread.java:834)
Instead of breaking in case the SSLEngine signals NEED_WRAP, which
leads to an endless loop while holding the
channelSelectedCallbackLock, we have to return, so that the
asynchronously invoked callback can aquire it, and do its work.
Smack currently does unnecessary escaping of XML text, where it
escapes e.g. '"' to '"'. This bloats the stanza size, especially
if JSON payloads are involved.
Fixes SMACK-892 (although there are probably still places where
XmlStringBuilder.escape() is used when XmlStringBuild.text() could
have been used).
This means that users get now exceptions with helpful error messages
instead of the dreaded ClassCastException, like
java.lang.ClassCastException: org.jivesoftware.smack.packet.StandardExtensionElement cannot be cast to org.jivesoftware.smackx.mam.element.MamElements$MamResultExtension
at
when StanzaView.getExtension(Class) is used to retrieve the extension.
When sending a stream-open-like element, it depends on the actual used
transport which element is send. For example, RFC6120-style TCP uses
<stream>, whereas the Websocket binding for XMPP uses <open/>.
Most of the times when we construct a stream-open-like element, we
want the jabber:client namespace. Hence add a constructor that does
select the namespace implicitly.
Before the existence of AbstractStreamOpen, StreamOpen sufficed our need
during sending an open stream element. Since the intention behind
introducing AbstractStreamOpen is to allow underlying transports provide
transport specific opening streams, these changes will further support
the cause.
This commit will allow us to send transport specific open element
which should be inherited from AbstractStreamOpen.
We previously only set the SM session ID to zero, but that is not
enough. On a clean shutdown, i.e. where we send a </stream> close tag,
we also have to nullify the unacknowledgedStanzas queue.
This PR aims to provide parseXrdLinkReferencesFor() method the ability
to parse forward to the first START_ELEMENT tag.The HttpLookupMethodTest
tests the HttpLookupMethod class by parsing String. This makes use of
PacketParserUtils.getParserFor(String), which already does forward
winding to reach START_ELEMENT. However when fetching endpoints from a
remote host meta data, PacketParserUtils.getParserFor(InputStream) is
used which doesn't do winding in any form. And thus, even though
HttpLookupMethodTest tests pass, this implementation would crash while
parsing remote host-meta.
We previously only set 'connected' after connectInternal()
returned. This could lead to notifyConnectionError() ignoring stream
error exceptions, e.g. when establishing TLS which happens also in
connectInternal(), because 'connected' was still 'false'.
2020-08-06 13:08:06.265 19830-20423/org.atalk.android D/SMACK: SENT (0):
<stream:stream xmlns='jabber:client' to='atalk.sytes.net' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' xml:lang='en'>
2020-08-06 13:08:06.333 19830-20424/org.atalk.android D/SMACK: RECV (0): ?xml version='1.0'?>
<stream:stream id='16420577292739412012' version='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' from='atalk.sytes.net' xmlns='jabber:client'>
<stream:error>
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Too many (20) failed authentications from this IP address (::ffff:42.60.7.13). The address will be unblocked at 05:15:34 06.08.2020 UTC
</text>
</stream:error>
</stream:stream>
2020-08-06 13:08:06.346 19830-20424/org.atalk.android I/aTalk: [241896] org.jivesoftware.smack.AbstractXMPPConnection.notifyConnectionError() Connection was already disconnected when attempting to handle org.jivesoftware.smack.XMPPException$StreamErrorException: policy-violation You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en'>Too many (20) failed authentications from this IP address (::ffff:42.60.7.13). The address will be unblocked at 05:15:34 06.08.2020 UTC</text></stream:error>
org.jivesoftware.smack.XMPPException$StreamErrorException: policy-violation You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en'>Too many (20) failed authentications from this IP address (::ffff:42.60.7.13). The address will be unblocked at 05:15:34 06.08.2020 UTC</text></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:966)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:898)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:921)
at java.lang.Thread.run(Thread.java:919)
Which eventually leads to a NoResponseException
org.jivesoftware.smack.SmackException$NoResponseException: No response
received within reply timeout. Timeout was 30000ms (~30s). While
waiting for establishing TLS
[XMPPTCPConnection[not-authenticated] (4)]
We now set 'connected' to 'true' as soon as the transport (e.g. TCP,
BOSH, …) is connected. While this is in other ways also sensible, it
also allows notifyConnectionError() to handle exceptions in the early
connection stage.
Thanks to Eng Chong Meng for reporting this.
We previously only looked in the registry for 'submit' type forms. But
also 'result' type forms may be send without field type
annotations. Same is true, but less likely, for 'form' type forms.
Instead of passing the passphrase back to the user via a
DisplayBackupCodeCallback, we directly return the passphrase
which is now represented by a class.
Also we now allow the user to provide the passphrase.
InBandBytestreamManager followed an unusual pattern: Within the
connectionTermianted() callback, it would remove itself from the
'managers' map. This allowed for multiple instances of an
InBandBytestreamManager to exist for the same connection, causing all
kinds of issues.
This fixes the issue by changing InBandBytestreamManager to use the
Smack-idiomatic pattern used by managers.
We also do no longer reset the listeners if the connection is
termianted, as listeners (and handlers) typically persist until they
are explicitly removed by the user.
As positive side-effect, the number of indeterministic unit-tests,
caused by using Thread.sleep(), is reduced. The executor service in
InitiationListener was also removed, because the IQ handler is already
called asynchronously to the connections main loop.
Thanks to Anno van Vliet for reporting this.
The current code would work just fine for a connection having
multiple endpoints. However, when there is only one endpoint
ConnectionAttemptState.nextAddress() would return null, since
connectionEndpointIterator has already iterated over the only
possible value in the contructor leading to a NullPointerException.
This means that during establishment of a connection having multiple
endpoints, the first value inside connectionEndpointIterator would
always be overlooked.
To ensure the thread starting the reader/writer threads sees them
running and eventually waits until the 'running' boolean is reset to
'false' upon connection termination.
Since the current variant of notifyConnectionError() does not execute
most of its work in a new thread, especially since instantShutdown()
is called in the invoking thread, we have to mark the connections
reader or writer threads as no longer running prior them invoking
notifyConnectionError(). Otherwise they will end up waiting for
themselves to terminate.
To make it clear that this will either return if the condition is
true *or* if a connection exception happened.
Also introduce waitFor(), which is deliberately not named
waitForCondition() because it carries a different semantic.
SMACK-888 has a mention of unreachable code and is now solved
under commit 0f7b7df.
This integration test tests those class entities which were to
be set by previously stated unreachable code.
Synchronize notifyConnectionError() so that only one exception is
handled and remove the ASYNC_BUT_ORDERED usage here. The
ASYNC_BUT_ORDERED was added with 7d2c3ac9f ("Do not call synchronized
methods in reader/writer thread"), but is no longer necessary, since
the Semaphores where replaced with conditions in the previous commit.
This continues the design started with e98d42790 ("SmackReactor/NIO,
Java8/Android19, Pretty print XML, FSM connections"), where the
exceptions that caused an operation to fail, are not recorded within
SynchronizationPoint but within the connection instance itself.
Since d65f2c932 ("Bump Error Prone version to 2.3.4 and fix new bug
patterns") the channel selected callback is no longer a final field of
the connection instance, hence it may be come null even if the
connection instance is still strongly referenced. Also the
ConnectionAttemptState class uses simply a lambda as callback, which
is also not strongly referenced otherwise.
The "channel selected" callback was wrapped in weak reference, so that
connection instances could get gc'ed if they are still connected but
the user lost all references to them. In this case, the weak reference
to the connection instance would become 'null' and
selectionKey.cancel() would be called.
This change means that a socket and its selection key of a "leaked"
connected connection instance continues to be part of the reactor. But
this may not be that bad: first, users are expected to manager their
connection instances, and disconnect them before they are
discarded. And secondly, at some point the connection likely will get
disconnected, and in this case, the socket and its selection key will
be removed from the reactor.
This moves the logic in AbstractXMPPConnection.getSmackTlsContext()
into the ConnectionConfiguration constructor.
Also introduce SslContextFactory and use it in
ConnectionConfiguration.
The field XMPPInputOutputStream.flushMethod was not initialized, which
could cause an NPE in the "switch (flushMethod)" found in
Java7ZlibInputOutputStream.getOutputStream().
Now that FormWriter, with its write() method, is gone, there is no
reason the FormReader method should still be named read(). Renaming to
getField() as this is what DataForm also uses.
`mgr.getNode(...)` method is not supposed to throw any type
of exception. It threw two kinds of exceptions: `NotConnectedException`
and `SmackException`.
By using `ThreadedDummyConnection.newInstance()` method,
`NotConnectedException` can be removed. And `SmackException`
can be removed by correctly building the DiscoverInfo packet.
Apply builder pattern to form fields and replace getVariable() with
getFieldName(). Refer to the field name as "field name" instead of
"variable" everyone, just as XEP-0004 does.
Improve the high-level form API: introduce FilledForm and FillableForm
which perform stronger validation and consistency checks.
Also add FormFieldRegistry to enable processing of 'submit' forms
where the form field types are omitted.
Smack also now does omit the form field type declaration on 'submit'
type forms, as it is allowed by XEP-0004.
The FaultTolerantNegotiator is the reason why Smack replies in a
non-standard way to file transfer requests: Smack puts two values in
the stream-method field, while the field is a list-single field,
i.e. a field which only allows one value.
Even if what Smack does is probably better, as it allows for a
fallback in case the bytestream transport fails, it is not standard
compliant. And, Jingle provide a proper fallback specification for
file transfers.
Fixes SMACK-561.
Those configurations where removed with version 1.13 (2010-07-12) of
XEP-0060.
This change is part of the effort to upgrade Smack's PubSub
implementation (SMACK-364).
In order to truely stay Java 8 compatible, declaring a source and
target compatiblity is not sufficient. Source compatiblity means that
the input, i.e. the code written in Java is compatible with that
particular version of the Java Language Specification (JLS). And
target compatibitliy means that the produced Java bytecode is
compatible with that particular version of the Java Virtual Machine
Specificiation (JVMS).
But there is actually a third dimension: the runtime
library (rt.jar). If signatures of methods change over java releases
within the runtime library, then the produced bytecode, may contain
calls to methods that do not exist with that exact same signature in
older java versions.
For example the family of Buffer subclasses changed the return value
of certain functions, for example flip() to not return Buffer, but the
concrete type of the current instance, e.g. CharBuffer.
If we compile now with a newer JDK, where the return type is
CharBuffer and not Buffer, then executing on an older JDK, where the
return type is Buffer, then we get java.lang.NoSuchMethodError(s)
thrown at us.
Fixes SMACK-651.
The previous site where the callback was invoked was only reached if
there was also a user status on the unvailable presence. But those are
not part of unavilable presences upon room destruction.
Fixes SMACK-888.
There is no need to duplicate that code. Also ensure that
userHasLeft() is invoked *before* the listeners are invoked, so that
e.g. isJoined() returns false in the listeners.
If it is announced as feature, entities sending fastened messages
expect the recipient to react somehow on those. And this is not the
case if this is just enabled in Smack.
Hence we disable it per default and require smack users to explicitly
enable it after they have setup the according stanza listeners.
The initState() method is also called in disconnect(). And if we reset
the closingStreamReceived sync point at disconnect, it will break the
WaitForClosingStreamElementTest integration test.
Return false as soon as the hashed value does not match. This is
sound, since every class that implements equals(Object) should also
implement hashCode().
Use EntityBareJid just as its done within PepManager. There is no need
for AsyncButOrdered in the PEP user managers, as PepManager already
takes care of that. Also the message carrying the PEP event should
always be the last parameter of the callbacks, as it is the least
important piece of information.
CI runs fail using OracleJDK8 with
/home/travis/build/igniterealtime/Smack/smack-omemo/src/main/java/org/jivesoftware/smackx/omemo/element/OmemoBundleElement_VAxolotl.java:30:
warning - Tag @see: missing final '>':
"<ahref="https://xmpp.org/extensions/xep-0384.html#usecases-announcing">XEP-0384:
OMEMO Encryption (Example 3)</a>."
Other JDKs do not report such an error.
The before/after class annotations are now no longer borrowed from
JUnit.
Also some integration tests used @After and/or @Before from JUnit,
which was never supported nor had any effected. Those methods got
deleted. But since there appears to be a desire for such a
functionality in sinttest, we should consider adding one.
This method was removed with 07da9ffb4 ("Do not have
Stanza.getExtension(String, String) return a generic type"). In order
to aide migration to the newer API, this commit re-adds the method and
marks it as deprecated.
This also removes the powermock dependency. Although powermock is a
fine library, it currently prevents dropping Junit4. And since we only
use the Whitebox API of powermock, this simply replaced powermock's
Whitebox with our own.
Ensure that he returned extension element is actually of the correct
type. It should not be common, but in theory, Smack's provider
architecture would allow for different types to be returned than the
ones one may expect.
The code in the integration-test/ directories should either be
migrated to sinttest (or unit tests), or get deleted. This is a first
small step towards this goal.
The smack-compression-jzlib subproject is obsolete since Java 7 de-
and inflate support was added with SMACK-389. Now it is time to remove
it.
Fixes SMACK-840.
This mini assignment kicked-off with replacing `pubsub` with `pep`,
but later transformed into something more.
The alterations and additions in this commit:
a) GeoLocation.
1) Add Documentation.
2) Add `EMPTY_GEO_LOCATION` to be used while
`stopPublishingGeoLocation()` is called.
b) Add GeoLocation IntegrationTest.
c) Add GeoLocation Listener.
d) GeoLocationManager.
1) Add Documentation.
2) Replace `pubsub` with `pep`.
3) Add methods to add-and-remove GeoLocationListeners.
4) Enable GeoLocation by default.
e) Add `package.info` for GeoLocation Integration Test.
Guus reports that the entity caps sinttest fails on openfire with an
timeout exception on Java 11. Very well possible that this is caused
by a changed scheduling behavior where the yield() thread nevertheless
dominates the, potential single, core.
The waitUntilThread() method is essentially a broken approach anyway
and should be replaced in the future.
Returning a generic would allow for
List<ExtensionElement> list = stanza.getExtension("foo", "bar");
to compile (Note the we are calling getExtension(), not
getExtension*s*()).
Users are encouraged to use the type safe getExtension(Class<? extends
ExtensionElement) variant instead.
Fixes SMACK-825.
This is a complete redesign of what was previously
XmppNioTcpConnection. The new architecture allows to extend an XMPP
client to server (c2s) connection with new transport bindings and
other extensions.
By not directly depending on Bouncycastle (BC), we avoid conflicts between
different bouncycastle versions. It is also part of the developers job
to take care that all required security primitives are available. If
they are provide by BC or some other security provider should not be
up to Smack to decide.
We now only add BC as test dependency to satisfy this requirement when
the unit tests are executed.
In the previous commit 46ddf071b ("gradle: add Android jar to
smack-android-extensions compile classpath") we already added the
Android jar using compileClasspath to smack-android-extensions. Now
use the same configuration for smack-android, since compileOnly is
deprecated.
Instead of marking the handle as not running by setting the handler's
value in the map to false, we now remove simply the key if there is no
handler running. This also means we no longer need to use a weak hash
map for this.
Also reduce the size of the synchronized blocks, mainly by scheduling
the handler outside of the synchronized(threadActiveMap) block.
Make some code better readable and add some more comments. Also do
start a new handler thread if the task threw.
Those, relatively new, listeners guarantee that the individual
listeners are not invoked in concurrently while preserving the
order. Exactly what MultiUserChat previously did with AsyncButOrdered,
which is now no longer needed and hence can be removed.
Fix a bug in the EqualsBuilder usage in UserTuneElement. Properly
synchronize listeners using CopyOnWriteSet. Make methods and fields
static where sensible and possible. Make
disableUserTuneNotifications() public (why was it private?). And a few
other minor fixes.
This commit will enable user to communicate
information about music to which user is listening.
This feature is less of a requirement and more like fun to me.
An attempt at solving SMACK-257.
Incase you see any chances of improvement,
please let me know :)
The assert on line 659 was causing my build to fail. Two issues caused
gitCommit to be empty.
1. The cmd 'git describe --always --tags --dirty=+' was not given
enough time to complete and had not exited which meant no text in
proc.text
2. The two git commands on lines 653 and 658 were run from the
CWD of my Eclipse IDE, not the $projectDir which caused git to return
an error 128.
To solve the two issues I added a waitForOrKill method call to
proc (like the srCmd had) and I set the execute to run in $projectDir
which I think was the intent/assumption in the original code.
Also add waitFor on git describe command.
If we do not peek at the scheduled actions in the reactors
synchronized block, then there is a kind of lost-update problem. While
Ractor.schedule() will call wakeup() on the selector, a thread could
have already determined the value of selectWait, while being blocked
at the start of the synchronized reactor section. Once it is able to
enter the section, it will use an outdated selectWait value.
This leads to scheduled actions not being executed on time.
Thanks to Eng ChongMeng for reporting this and suggesting the fix.
Smack did this for a long time, since eb56f8a55 ("GSSAPI work by Jay
Kline (SMACK-218)."). Not always in a static block though. But
irregardless this is bad practice as it causes side-effects and may
overrides settings.
For example, one users reports:
java.lang.SecurityException: java.io.IOException: gss.conf (No such file or directory)
at sun.security.provider.ConfigFile$Spi.<init>(ConfigFile.java:137)
at sun.security.provider.ConfigFile.<init>(ConfigFile.java:102)
at sun.reflect.GeneratedConstructorAccessor119.newInstance(Unknown Source)
Besides the way the transport handles the stream after SASL
<success/>, the SASL logic is independend from the underlying
transport (BOSH, TCP, …). Hence move it up into
AbstractXMPPConnection.
This also has the benefit that we can make some more methods private
or package-private.
Also introduce XmlStringBuilder.optTextChild(), which causes some
associated changes.
Thanks to PolFW, who writes:
A SASLErrorException is thrown before we have received the "<success
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>". This is because
SASLAuthentication is keeping a reference to a "saslException" so to
clear that after a authentication failure we have to invoke again
connect on the xmpptcpconnection to initialize again the
saslAuthentication. But it doesn't solve the issue because an
AlreadyConnectedException is thrown before the initialisation of the
"this.saslAuthentication.init();"
Note that the user uses one time tokens for authentication.
Since 2f667f95a ("gradle: Remove archives configuration") the
:smack-repl:printXmppNioTcpConnectionStateGraph
JavaExec task failed with
> Task :smack-repl:printXmppNioTcpConnectionStateGraph FAILED
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.jivesoftware.smack.SmackConfiguration.getVersion(SmackConfiguration.java:108)
at org.jivesoftware.smack.AbstractXMPPConnection.<clinit>(AbstractXMPPConnection.java:187)
at org.igniterealtime.smack.smackrepl.StateGraph.main(StateGraph.java:37)
Caused by: java.lang.IllegalStateException: Could not parse Smack configuration file
at org.jivesoftware.smack.SmackInitialization.<clinit>(SmackInitialization.java:100)
... 3 more
Caused by: java.lang.IllegalStateException: Could not load a XmlPullParserFactory via Service Provider Interface (SPI)
at org.jivesoftware.smack.xml.SmackXmlParser.getXmlPullParserFactory(SmackXmlParser.java:34)
at org.jivesoftware.smack.xml.SmackXmlParser.newXmlParser(SmackXmlParser.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.getParserFor(PacketParserUtils.java:76)
at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:144)
at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:139)
at org.jivesoftware.smack.SmackInitialization.<clinit>(SmackInitialization.java:97)
... 3 more
because no XmlPullParser was registered via SPI. The 'archives'
configuration which was removed with 2f667f95a ("gradle: Remove
archives configuration"), previously pulled in the parser.
Just like smack-android delcares a dependency on smack-xmlparser-xpp3,
smack-java7 should declare a dependency on smack-xmlparser-stax.
Since using a pipe, as we did previously would not error the target if
the first command in the pipe fails.
It is still far from ideal, since the dot file is also generated if
the gradle command fails. At some point, this should probably become
part of gradle build step instead of shelling out to a Makefile.
and FileTestUtil in favor of commons-io. This is required because
Eclipse won't put src/test code into the classpath of src/main
code (even though gradle was configured with an according
dependency).
gradles compile command (which is deprecated and should be replaced with implementation) includes the arguments resources into the result jar.
That means that smack-android will contain resources found at the android boot classpath.
This results in a +~11mb increase in size of the resulting apk when including Smack as a composite build. The increase comes from 11mb of Android resources, mainly drawables.
compileOnly (formerly provided) on the other hand will assert that the android.jar classes are provided by the system, which is probably what we want in this case.
there is no reason why we want to store the bytes of the base64
encoded string. Simply store the string itself.
Also add a convenience method to get the decoded bytes of the PubKey.
- Reduce the amount of types that are subtypes of NamedElement. See
javadoc of NamedElement for rationale.
- Work more with XmlEnvironment in XmlStringBuilder.
- Some minor changes to XmlStringBuilder API.
to ensure that javadocAll works correctly. A nice side-effect, this
also ensures that the package-info.java symbolic links are still
correct and haven't been replaced by some IDE or editor with the
content of the link target.
This is needed for javadocAll since otherwhise there will be
smack-core/src/main/java/org/jivesoftware/smack/package-info.java:21:
warning: a package-info.java file has already been seen for
package org.jivesoftware.smack
warnings.
by using PubSubManager.tryToPublishAndPossibleAutoCreate().
This also swaps the parameters of the method.
Thanks to Guus der Kinderen for suggesting this.
Those exception are caused by I/O operations in the OmemoStore, which
is now declaring that it throws those (since it is not uncommon for
I/O operations to cause IOExceptions). After all, this is nicely
demonstrated as this change is caused by switching with this commit to
the Android API 19 compatible methods in FileBasedOmemoStore, which
throw.
The library can not decide what to do in case of those exceptions,
hence it is sensible to expose them to the user.
Although it it not that unreliable, it causes false negatives once in
a while. This is because the standard Java SE API does not provide a
way to force a *full* garbage collection run, we need to resort to
unreliable hacks to trigger one.
The test itself is still useful to diagnose or refute alleged memory
leaks.
This commit also move the test from JUnit 4 to Junit 5.
This patch makes it possible to change the stream-level language as part
of the connection configuration, to allow a properly implemented
entities to provide i18n'ed response messages. The Locale type is used
for this configuration, and the effective language string can be
obtained via `ConnectionConfiguration.getXmlLang()`.
This code does not cover XMPPBOSHConnection!
Signed-off-by: Georg Lukas <georg@op-co.de>
which is the probably the better choice here anyway. And it also
prevents the following failure on POM creation:
$ gradle uploadArchives
> Task :smack-android:uploadArchives FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':smack-android:uploadArchives'.
> Could not publish configuration 'archives'
> Could not write to file
'/home/flo/data/code/smack/smack-android/build/poms/pom-default.xml'.
See also
https://discuss.gradle.org/t/gradle-fails-to-create-pom-with-the-configuration-to-scope-mapping-is-not-unique/32087
Ensuring that the node has no items in
transientNotificationOnlyNodeWithoutItemTest() is not right. An
implementation is free to create an item with an ID and return it. The
item is just not guaranteed to be persistent.
Also add a dummy payload to
transientNotificationOnlyNodeWithItemTest().
If run in parallel with other unit tests, especially onces that open
up a proxy, this test could fail, because another unit test actually
had an proxy running on the very address this unit test assumes to be
no proxy running.
We now use an IP address from RFC 5737's TEST-NET-1 address block,
which should never be available.
and not NullPointerException. Altough this differs from
java.util.Objects behavior, throwing an IllegalArgumentException
appears more sensible and makes it easier to catch it in Smack's
parsing function.
Without this, newly scheduled runnables would potentially not be
scheduled in case the reactor thread was blocking in select(0)
indefinetly.
Thanks to Eng ChongMeng for reporting this.
As result it is now also possible to start multiple local SOCKS5
proxies with different port, which is usually not necessary in real
life but useful for unit tests.
'parseAndProcessStanza()' throws generic Exceptions.
Since there are plenty of exceptions that should not be
catched by smack, it's better to throw Type Specific Exceptions.
This Commit is was in response to SMACK-839.
This is based on the patch provided by Georg Lukas, modified to take
XMPP domain names that can not be represented as DNS names into
account. See c42d2eea24 (r269250137)
Fixes SMACK-870.
It appears that we observe a partion GC run on some systems,
especially ones with few resources. Hopefully this increases the
chances to observe the expected GC affects so that the unit test
passes also on those systems.
Because an failing test on Travis was observered using a timeout of
60s:
org.jivesoftware.smackx.muc.MucMemoryLeakTest > mucMemoryLeakTest FAILED
java.lang.AssertionError: No reference found after 60000ms
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:712)
at org.jivesoftware.smack.util.MemoryLeakTestUtil.assertReferencesQueueSize(MemoryLeakTestUtil.java:110)
at org.jivesoftware.smack.util.MemoryLeakTestUtil.noResourceLeakTest(MemoryLeakTestUtil.java:103)
at org.jivesoftware.smackx.muc.MucMemoryLeakTest.mucMemoryLeakTest(MucMemoryLeakTest.java:29)
Introducing Smack's own XmlPullParser interface which tries to stay as
compatible as possible to XPP3. The interface is used to either wrap
StAX's XMLStreamReader if Smack is used on Java SE, and XPP3's
XmlPullParser if Smack is used on on Android.
Fixes SMACK-591.
Also introduce JUnit 5 and non-strict javadoc projects.
and also call notifyConnectionError() on exception thrown by
openStream().
In hindsight I wonder why openStream() was ever called in the writer
thread, as it only caused unnecessary synchronization overhead, as can
be seen by the initialOpenStreamSend synchronization point.
Smack will throw an IllegalArguementException if extremely
long reply timeouts are tried to be set. I assumed currentTimeMilli()
to be the boundary condition as per SMACK-718
XEP-0060 prohibits publishing a request that contains an item to a node that
is both 'notification-only' and 'transient' (section 7.1.3.6)
In commit 8ed872ca63 the existing pubsub publication
test was modified (to resolve a different issue) to operate on a node that's both
'notification-only' and 'transient'. This resulted in a test that should return
an error, even though the test implementation didn't expect one.
This commit explicitly verifies that publishing an item to such a node causes
an error to be returned. A new test is added that verifies that publishing an
event notification does succeed.
The Smack Integration tests can use an admin account to provision
accounts that are used by the tests. This admin account uses an XMPP
connection to interact with the server-under-test.
When the tests are over, this account should be disconnected
explicitly, to prevent stream management from keeping it alive longer
than it needs to.
This makes the system select the "best" available provider.
Also the 'BC' provider in newer Android version does not longer
implement certain Ciphers, which causes an NoSuchAlgorithmException if
the Cipher is requested explicitly by the 'BC' provider:
E/XmppService: XmppServiceConnection - Error while sending pending messages
org.jivesoftware.smackx.omemo.exceptions.CryptoFailedException: java.security.NoSuchAlgorithmException: The BC provider no longer provides an implementation for Cipher.AES/GCM/NoPadding. Please see https://android-developers.googleblog.com/2018/03/cryptography-changes-in-android-p.html for more details.
at org.jivesoftware.smackx.omemo.OmemoService.encrypt(OmemoService.java:375)
at org.jivesoftware.smackx.omemo.OmemoService.createOmemoMessage(OmemoService.java:537)
at org.jivesoftware.smackx.omemo.OmemoManager.encrypt(OmemoManager.java:341)
at org.jivesoftware.smackx.omemo.OmemoManager.encrypt(OmemoManager.java:314)
at es.iecisa.xmppservice.XmppServiceConnection.lambda$sendMessage$0(XmppServiceConnection.java:516)
at es.iecisa.xmppservice.-$$Lambda$XmppServiceConnection$aBU_80chagvypMTSd-aSm7pRQRY.run(Unknown Source:4)
at java.lang.Thread.run(Thread.java:764)
Caused by: java.security.NoSuchAlgorithmException: The BC provider no longer provides an implementation for Cipher.AES/GCM/NoPadding. Please see https://android-developers.googleblog.com/2018/03/cryptography-changes-in-android-p.html for more details.
at sun.security.jca.Providers.checkBouncyCastleDeprecation(Providers.java:563)
at sun.security.jca.Providers.checkBouncyCastleDeprecation(Providers.java:346)
at javax.crypto.Cipher.createCipher(Cipher.java:722)
at javax.crypto.Cipher.getInstance(Cipher.java:717)
at javax.crypto.Cipher.getInstance(Cipher.java:674)
at org.jivesoftware.smackx.omemo.util.OmemoMessageBuilder.setMessage(OmemoMessageBuilder.java:169)
at org.jivesoftware.smackx.omemo.util.OmemoMessageBuilder.<init>(OmemoMessageBuilder.java:116)
at org.jivesoftware.smackx.omemo.OmemoService.encrypt(OmemoService.java:372)
at org.jivesoftware.smackx.omemo.OmemoService.createOmemoMessage(OmemoService.java:537)
at org.jivesoftware.smackx.omemo.OmemoManager.encrypt(OmemoManager.java:341)
at org.jivesoftware.smackx.omemo.OmemoManager.encrypt(OmemoManager.java:314)
at es.iecisa.xmppservice.XmppServiceConnection.lambda$sendMessage$0(XmppServiceConnection.java:516)
at es.iecisa.xmppservice.-$$Lambda$XmppServiceConnection$aBU_80chagvypMTSd-aSm7pRQRY.run(Unknown Source:4)
at java.lang.Thread.run(Thread.java:764)
The NPE is caused by an inbound presence stanza without the 'from'
attribute set. The stacktrace of the NPE is:
FATAL EXCEPTION: Smack Cached Executor
Process: de.fhg.ivi.senetz.mobile.android.mbk.debug, PID: 13365
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:944)
at org.jivesoftware.smack.roster.Roster.getPresencesInternal(Roster.java:374)
at org.jivesoftware.smack.roster.Roster.getOrCreatePresencesInternal(Roster.java:388)
at org.jivesoftware.smack.roster.Roster.access$1100(Roster.java:94)
at org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run(Roster.java:1519)
at org.jivesoftware.smack.AsyncButOrdered$Handler.run(AsyncButOrdered.java:121)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
Thanks to Marcel Heckel for reporting this.
Fixes SMACK-861.
In case an exception happens in connect()/login() the
'disconnectedButResumable' boolean may (still) be set. Which causes
only one of the reader and writer threads to exit, typically the
reader thread, because shutdown() will bail out very early. This
leaves a dangling (writer) thread causing memory leaks and deadlocks
on a subsequent connect()/login().
in case length is zero. Also do throw a NegativeArraySizeException if
length is negative instead of returning null.
This fixes the following sporadic test issue:
org.jivesoftware.smackx.ox.PainlessOpenPgpProviderTest > encryptDecryptTest FAILED
java.lang.AssertionError
at org.jivesoftware.smack.util.XmlStringBuilder.escape(XmlStringBuilder.java:425)
at org.jivesoftware.smackx.ox.element.EncryptedOpenPgpContentElement.addCommonXml(EncryptedOpenPgpContentElement.java:65)
at org.jivesoftware.smackx.ox.element.CryptElement.toXML(CryptElement.java:51)
at org.jivesoftware.smackx.ox.element.CryptElement.toXML(CryptElement.java:31)
at org.jivesoftware.smack.packet.Element.toXML(Element.java:41)
at org.jivesoftware.smackx.ox.element.OpenPgpContentElement.toInputStream(OpenPgpContentElement.java:186)
at org.jivesoftware.smackx.ox.crypto.PainlessOpenPgpProvider.encrypt(PainlessOpenPgpProvider.java:136)
at org.jivesoftware.smackx.ox.PainlessOpenPgpProviderTest.encryptDecryptTest(PainlessOpenPgpProviderTest.java:155)
because EncryptedOpenPgpContentElement rpad field was sometimes
'null' in case the random function returned '0' as length.
Previously, the costly method 'ServiceDiscoveryManager.getInstance()'
was called at multiple instances inside MultiUserChatManager.
In this commit I wish to replace this call by saving a private final
instance of 'ServiceDiscoveryManager' which will is an attempt at
solving SMACK-836.
and deprecate createEntry().
createEntry() would also send a subscription request which may is
suprising given that you can also create an roster item without having
to send a subscription request out.
This also fixes a bug in
LowLevelRosterIntegrationTest.testPresenceEventListenersOffline()
where createEntry() was used, which would also trigger a presence
subscription request which in turn made the test fail if the
SubscribeListener of ensureSubscribedTo() was not yet set
up. So the test would fail depending on the timing.
especially *after* the sync points have been notified so that a
potential thread currently callin gconnect()/login() throws and leaves
the synchronized section.
This commit is more or less equivalent to
3ded023629 of the 4.3 branch.
as it is not neccessary and causes stalls and deadlocks with a
concurrent connect()/login() (which could be resolved interrupting the
connect()/login() calling thread):
"Smack Reader (0)" daemon prio=5 tid=21 Blocked
| group="main" sCount=1 dsCount=0 obj=0x12c84670 self=0x7e072ca200
| sysTid=14965 nice=0 cgrp=default sched=0/0 handle=0x7e06155450
| state=S schedstat=( 63430626 3034269 21 ) utm=5 stm=0 core=2 HZ=100
| stack=0x7e06053000-0x7e06055000 stackSize=1037KB
| held mutexes=
at org.jivesoftware.smack.tcp.XMPPTCPConnection.notifyConnectionError(XMPPTCPConnection.java:-1)
- waiting to lock <0x0ec6e6bb> (a org.jivesoftware.smack.tcp.XMPPTCPConnection) held by thread 22
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$3900(XMPPTCPConnection.java:154)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1330)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$900(XMPPTCPConnection.java:1064)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1081)
at java.lang.Thread.run(Thread.java:761)
"connect" prio=5 tid=22 Waiting
| group="main" sCount=1 dsCount=0 obj=0x12c8e820 self=0x7e19bcd600
| sysTid=15047 nice=0 cgrp=default sched=0/0 handle=0x7e05ee4450
| state=S schedstat=( 14067083 7475835 14 ) utm=1 stm=0 core=0 HZ=100
| stack=0x7e05de2000-0x7e05de4000 stackSize=1037KB
| held mutexes=
at java.lang.Object.wait!(Native method)
- waiting on <0x0c058b14> (a java.lang.Object)
at java.lang.Thread.parkFor$(Thread.java:2127)
- locked <0x0c058b14> (a java.lang.Object)
at sun.misc.Unsafe.park(Unsafe.java:325)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:161)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:840)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:446)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.initConnection(XMPPTCPConnection.java:685)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:942)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:417)
- locked <0x0ec6e6bb> (a org.jivesoftware.smack.tcp.XMPPTCPConnection)
at org.yaxim.androidclient.service.SmackableImp.connectAndLogin(SmackableImp.java:717)
- locked <0x0ec6e6bb> (a org.jivesoftware.smack.tcp.XMPPTCPConnection)
at org.yaxim.androidclient.service.SmackableImp.doConnect(SmackableImp.java:304)
at org.yaxim.androidclient.service.SmackableImp$5.run(SmackableImp.java:391)
We assume that the connection is good even if there was no ping
result but a stanzas within the ping interval.
In some case we have produced so much load, that the ping result
was not delivered in time because so many other packets were
delivered before.
If a stream resume fails, smack will re-send all queued stanzas after a
reconnect. However, it does not make sense to re-send them:
* IQs / IQ responses have probably timed out
* MUC messages and PMs will be rejected as you haven't rejoined yet
* regular messages should be amended with a <delay> element
This patch adds a StanzaDroppedListener interface to the
XMPPTCPConnection. If at least one StanzaDroppedListener is provided,
all queued messages will be drained into the StanzaDroppedListener(s).
Otherwise, the original behavior of attempting to transmit them will be
followed.
Discussion: https://discourse.igniterealtime.org/t/xep-0198-resume-failure-reconnect-resending-of-muc-messages/83510/3
Signed-off-by: Georg Lukas <georg@op-co.de>
To prevent timeouts when joining very large MUCs we now reset the
self-presence collector's timeout for every other (occupant) presence
we receive.
Fixes SMACK-859.
to clean up the state build up by connect().
Related to SMACK-855 there is the possiblitiy of a stray (writer)
thread if, for example, tlsHandled.checkifSuccessOrWaitorThrow() in
XMPPTCPConnection.connectInternal() throws. This commit should prevent
that.
This commit adds
- SmackReactor / NIO
- a framework for finite state machine connections
- support for Java 8
- pretty printed XML debug output
It also
- reworks the integration test framework
- raises the minimum Android API level to 19
- introduces XmppNioTcpConnection
Furthermore fixes SMACK-801 (at least partly). Java 8 language
features are available, but not all runtime library methods. For that
we would need to raise the Android API level to 24 or higher.
The inetAddressAndPort String is redundant since
a2743549b8, because we now construct the
InetSocketAddress earlier and can hence use it in the log statement.
The purpose of the "maybeCompressFeaturesReceived" synchronization
point is to wait for the stream features after authentication. This is
not really reflected by its name and furthermore its
checkIfSuccessOrWait() method was only invoked if compression was
enabled, but we always want to wait for the stream features after
authentication. Hence move the call before the isCompressionEnabled()
check and one layer up in the call stack.
Fixes SMACK-846.
Some clients (read: Gajim) store boolean values as `0` and `1` instead
of `false` and `true`, which is legal for the XML boolean type.
Signed-off-by: Georg Lukas <georg@op-co.de>
Fix for SMACK-841
Since Smack 4.2.4, the getPresencesInternal method in the Roster class
can return a LruCache object, which is a LinkedHashMap with access
order. This means that any access using get or getOrDefault will be a
modification of the Map. If you loop over the keySet of the Map and
there are more than one, the second call to get will throw a
ConcurrentModificationException!
Since the keys are only used here to obtain the corresponding
values, the simplest solution is to just loop over the values instead.
The documentation states that the debugging jar is called
smackx-debug.jar. However, according to maven central, that name was
only used until 3.2.1, newer releases (including 4.4.0-alpha1) only
distribute smack-debug.jar, which contains the debugger as advertised.
Type 'groupchat' message stanzas are not like others, they usually
require special handling. Hence such a filter is usually an indication
that multiple concepts are intermixed.
* Created filters to be used with incoming and outgoing message stanzas
* Added a list of ChatMarkersListener and its add and remove methods.
* Added a stanza listener for outgoing messages.
* Added a stanza listener for incoming messages.
* Added discover feature for XEP-0333.
* Added methods to inform a message was: received, displayed or ack
* Added javadoc autor tag.
Originally discovered by Paul Schaub:
Fixes an inconvenience, where an IQ with the implicit namespace
`jabber:client` would append the namespace to an error child element
like this:
```
<iq (xmlns='jabber:client) <!-- in parenthesis since the NS is implicit --> ... >
<error xmlns='jabber:client' <!-- this NS is too much --> ... />
</iq>
``
Changes:
Rework integration tests
New structure of base integration test classes
bump dependency on signal-protocol-java from 2.4.0 to 2.6.2
Introduced CachingOmemoStore implementations
Use CachingOmemoStore classes in integration tests
Removed OmemoSession classes (replaced with more logical OmemoRatchet classes)
Consequently also removed load/storeOmemoSession methods from OmemoStore
Removed some clutter from KeyUtil classes
Moved trust decision related code from OmemoStore to TrustCallback
Require authenticated connection for many functions
Add async initialization function in OmemoStore
Refactor omemo test package (/java/org/jivesoftware/smack/omemo -> /java/org/jivesoftware/smackx)
Remove OmemoStore method isFreshInstallation() as well as defaultDeviceId related stuff
FileBasedOmemoStore: Add cleaner methods to store/load base data types (Using tryWithResource, only for future releases, once Android API gets bumped)
Attempt to make OmemoManager thread safe
new logic for getInstanceFor() deviceId determination
OmemoManagers encrypt methods now don't throw exceptions when encryption for some devices fails. Instead message gets encrypted when possible and more information about failures gets returned alongside the message itself
Added OmemoMessage class for that purpose
Reworked entire OmemoService class
Use safer logic for creating trust-ignoring messages (like ratchet-update messages)
Restructure elements/provider in order to prepare for OMEMO namespace bumps
Remove OmemoManager.regenerate() methods in favor of getInstanceFor(connection, randomDeviceId)
Removed some unnecessary configuration options
Prepare for support of more AES message key types
Simplify session creation
Where possible, avoid side effects in methods
Add UntrustedOmemoIdentityException
Add TrustState enum
More improved tests
When no join was properly registered, a nickname will not be defined.
In that case, attempting to construct the from address for the 'leave'
presence stanza will result in:
java.lang.IllegalArgumentException: The Resourcepart must not be null
This commit prevents that, by verifying that the nickname is non-null,
before sending that stanza.
Since it is accessed concurrently. And also may cause a
ConcurrentModificationException when the MultiUserChatManager tries to
re-join the joined rooms.
Fixes SMACK-819.
This commit also changes the usage of the android.jar found in the
androidBootClasspath gradle variable, because
AndroidSmackInitializer.initialize(Context) pulls in
org.minidns.dnsserverlookup.android21.AndroidUsingLinkProperties
from minidns-android21, which has a @TargetApi annotation which is
only available on Android SDK API level 16 or higher. Otherwhise we
would get
> Task :smack-android:compileJava FAILED
/home/flo/.gradle/caches/modules-2/files-2.1/org.minidns/minidns-android21/0.3.0/13f273d095e51d701283062a25e867f3ff26d258/minidns-android21-0.3.0.jar(/org/minidns/dnsserverlookup/android21/AndroidUsingLinkProperties.class): warning: Cannot find annotation method 'value()' in type 'TargetApi': class file for android.annotation.TargetApi not found
/home/flo/.gradle/caches/modules-2/files-2.1/org.minidns/minidns-android21/0.3.0/13f273d095e51d701283062a25e867f3ff26d258/minidns-android21-0.3.0.jar(/org/minidns/dnsserverlookup/android21/AndroidUsingLinkProperties.class): warning: Cannot find annotation method 'value()' in type 'TargetApi'
error: warnings found and -Werror specified
1 error
when compiling smack-android.
Also add minidns-core as dependency to smack-core. This requires
increasing the minimum required Android SDK level to 9, as this is
what MiniDNS requires.
The following wild problem appeared:
Smack currently checks for Android API compatiblity by creating a
extra 'compileAndroid' task, which has the boot classpath set to the
corresponding android.jar of the minimum Android API level required by
Smack. This ensures that the task failes if we use methods which are
not part of this Android API level.
Now setting javac's source/target compatibility level to Java 8 in
itself is not a problem, newer Android build toolchains will desugar
most Java 8 ishms to the Java 7 flavor supported by the dex tool,
hence Android projects are able to consume a Java 8 enabled Smack.
But as soon as we use lambdas with an minimum Android API level
lower than 26, the compileAndroid task will fail with:
com.sun.tools.javac.code.Symbol$CompletionFailure:
class file for java.lang.invoke.MethodHandles$Lookup not found.
Re-opens SMACK-801.
with the same matching feature announced.
Consider for example PubSub where usually the service itself announces
the PubSub feature as part of PEP, and where an additional PubSub
component exists. The old logic will just lookup the first matching
service with a PubSub feature announcement and check if for a matching
identiy. If we look for a real PubSub service, but stumble first over
user's service with PEP, then findService() will return 'null' although
there would have been a valid PubSub service.
Fixes SMACK-805.
At some point IQChildElementXmlStringBuilder was modified to add the
closing quote around the namespace. this was not reflected in these
element extensions
in case hostAddresses was null, the isEmpty() check before the log()
invocation would throw an NPE. Thanks to Ingo Bauersachs for reporting
this.
Fixes SMACK-788.
using the default algorithm. Instead continue with 'null' as value of
the KeyManager[] array (kms). This makes the SSLContext.init() methods
to search the default security providers for implementations, which is
also OK.
This change is needed because it appears that on Android
KeyManagerFactory.getDefaultAlgorithm returns 'SunX509', which
subsequently results in
W/AbstractXMPPConnection: Connection XMPPTCPConnection[not-authenticated] (0) closed with error
java.security.NoSuchAlgorithmException: KeyManagerFactory SunX509 implementation not found
at org.apache.harmony.security.fortress.Engine.notFound(Engine.java:190)
at org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:139)
at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:77)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:747)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1200(XMPPTCPConnection.java:149)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1053)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:980)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:996)
at java.lang.Thread.run(Thread.java:818)
Note that this is possibly because the Secuurity Provider was
not (yet) intialized.
New stanzas sent directly after stream resumption might have been added
to unacknowledgedStanzas before the old unacknowledged stanzas
are resent. This caused new stanzas to be sent twice and later led
to a StreamManagementCounterError.
Fixes SMACK-786
by implementing a new logic how the messages are retrieved.
Previously in case the node list has exactly one item, the method
would perform an unnecessary call to nextResult() causing a delay.
Fixes SMACK-785.
Remove the "if (!joined) return" guard in leave() this allows to
resync the instances state with the real world state in case they ever
get out of sync.
Also call userHasLeft() in even if leave() throws and in certain
situations if destroy() throws.
Thanks to Дамян Минков and Ingo Bauersachs for pointing this out.
by calling String.equals() on the constant string and not on the
return value of parser.getName().
Also perform the access to 'parser' on a different LOC than
equals(). This should help debugging things like
okt 25, 2017 2:02:54 PM org.jivesoftware.smack.AbstractXMPPConnection callConnectionClosedOnErrorListener
WARNING: Connection XMPPTCPConnection[***@***/***] (0) closed with error
java.lang.NullPointerException
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1194)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:982)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:998)
at java.lang.Thread.run(Thread.java:745)
which where recently reported on the forums.
A stanza with <error><text>Some text</text></error>, i.e. without a
xml:lang attribute, did not return the value 'Some text' in
getDescriptiveText().
Insert the empty string as key when the attribute is not present while
parsing the xml. When writing, omit the attribute if the key is the
empty string.
Previously StanzaListeners and Collectors where able to receive IQ of
type 'get' or 'set' (i.e., IQ requests) when no IQRequestHandler was
registered. By moving the 'return' statement one level down, even
listeners/collectors won't receive them.
and some further minor jingle fixes:
- deprecate getJingleTransport() in favor of getTransport()
- Jingle.Builder now checks if the session ID is not empty
The test failed because the ArrayList - in contrast
to the underlying Set - did not check for duplicates
on insert. Under certain circumstances this lead to
an index out of bounds exception because the list in
the test contained duplicated entries which were not
present in the set of the Socks5Proxy.
I fixed the issue by only inserting the address when
it was not in the list before.
as otherwhise there may be a GroovyCastException:
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'java.io.Console@148b13e5' with class 'java.io.Console' to class 'org.gradle.api.tasks.Console'
at build_5dq456k95ni7h1f54hn45uzb7$_run_closure2.doCall(/home/flo/data/code/smack/build.gradle:194)
at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)
at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:221)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:145)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:315)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:225)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:138)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:35)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy59.graphPopulated(Unknown Source)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:111)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:230)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:227)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:161)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:95)
at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:66)
at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:31)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:281)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:254)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:33)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:247)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:182)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
with some Gradle versions.
as it would cause "Cannot change dependencies of configuration after
it has been included in dependency resolution" errors with Gradle >=
3.
Thanks to James Justinic for pointing this out.
- Change visibility of some Socks5Bytestreams code.
- Add central ThreadPool
- Move FullJidAndSessionId in own class
- More complete JingleSession class
- More complete JingleUtil class
- Improved tests
This commit adds the modules smack-omemo and smack-omemo-signal.
smack-omemo is licensed under the Apache license like the rest of the smack project.
smack-omemo-signal on the other hand is licensed under the GPLv3.
Due to the fact, that smack-omemo is not of much use without smack-omemo-signal,
the OMEMO feature can currently only be used by GPLv3 compatible software.
This may change in the future, when a more permissively licensed module becomes available.
Fixes SMACK-743.
A start for the new Jingle API. Since Jingle is a single IQ with many
plugable extensions, there are some particularities we need to deal
with, e.g. jingle users have to register with JingleManager.
This is untested code. There may be drangons.
In case the server provided nonce contained one or more equals
characters ("=") the part.split("=") call would return more then the
expected two key/value parts. Hence we simply use part.split("=", 2).
Also made the unit test check for this case.
Fixes SMACK-755
Previously publish() was "asynchronously" in that sense that the response
of the IQ as *not* awaited, and send() would wait for the
responses. It makes no sense to have that functionality this way.
Instead we now make publish() to the right thing, i.e., wait for an IQ
result, make send() a proxy for publish(), and mark send() deprecated.
In the future, there may be a publishAsync() method which returns a
Future instance.
This caused the WaitForClosingStreamElementTest integration test to
fail, because the last presences stanzas, which are send after done()
in the writer thread would return true, are not added to the
unacknowledgedStanzas queue.
The result was:
SEVERE: WaitForClosingStreamElementTest.waitForClosingStreamElementTest (LowLevel): Failed
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.invokeLowLevel(SmackIntegrationTestFramework.java:466)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runTests(SmackIntegrationTestFramework.java:375)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.run(SmackIntegrationTestFramework.java:165)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.main(SmackIntegrationTestFramework.java:84)
Caused by: java.lang.AssertionError: Sync poing yielded failure exception
at org.jivesoftware.smack.WaitForClosingStreamElementTest.waitForClosingStreamElementTest(WaitForClosingStreamElementTest.java:46)
... 8 more
Caused by: org.jivesoftware.smack.sm.StreamManagementException$StreamManagementCounterError: There was an error regarding the Stream Mangement counters. Server reported 3 handled stanzas, which means that the 3 recently send stanzas by client are now acked by the server. But Smack had only 1 to acknowledge. The stanza id of the last acked outstanding stanza is FqL1X-144
at org.jivesoftware.smack.tcp.XMPPTCPConnection.processHandledCount(XMPPTCPConnection.java:1847)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$2600(XMPPTCPConnection.java:149)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1176)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:980)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:996)
at java.lang.Thread.run(Thread.java:745)
by extending Manager.
Because FileTransferNegotiator will hold a strong reference to the
StreamNegotiators, which will eventually prevent XMPPConnection from
being GC'ed if no weak references in StreamNegotiator are used.
Thanks to Werner Glanzer for pointing this out.
Daniele Ricci reporting the following NPE using Smack 4.1.9
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.String.indexOf(int)' on a null object reference
at org.jxmpp.util.XmppStringUtils.parseBareJid(XmppStringUtils.java:124)
at org.jivesoftware.smack.roster.Roster$RosterPushListener.handleIQRequest(Roster.java:1416)
at org.jivesoftware.smack.AbstractXMPPConnection$2.run(AbstractXMPPConnection.java:1061)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
This is possibly caused by a service sending roster pushes for unbound
connections, i.e. where getUsers() returns 'null'. We now log such
situations instead throwing an NPE.
To prevent
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:788)
at java.util.HashMap$KeyIterator.next(HashMap.java:815)
at org.jivesoftware.smackx.ping.PingManager.pingMyServer(PingManager.java:252)
at org.kontalk.service.msgcenter.MessageCenterService$3.run(MessageCenterService.java:1114)
at java.lang.Thread.run(Thread.java:818)
Thanks to Daniele Ricci for reporting this.
We can't always setup the carbons listener in the constructor of the
manager, as the our local XMPP address may not be available yet. So
setup the carbons listener on a connection listener *and* in the
constructor.
I'm not sure why i've put the removeAsyncStanzaListener() call into
the finally block. If callback.processStanza(Stanza) takes a long
time (or even blocks), then it would appear to the "no response"
handling Runnable as if there was no response, when in fact there was
one.
instead of an EntityFullJid, because according to XEP-0045 § 7.8.1.:
"The <room@service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant
JID of the inviter …"
The jids list doesn't have to be lazy initialized, because every IQ of
that type is guaranteed to contain at least one JID.
Also use ParserUtils.getJidAttribute().
for the last message. We now count the number of messages we want to
retrieve, and don't wait for another message if we have already
received all.
Thanks to King Jeong Hun for reporting this.
Fixes the following exception thrown if the user had entered a non-existend XMPP domain:
java.lang.IllegalArgumentException: Must provide at least one InetAddress
at org.jivesoftware.smack.util.dns.HostAddress.<init>(HostAddress.java:55)
at org.jivesoftware.smack.util.dns.DNSResolver.lookupHostAddress(DNSResolver.java: 56)
at org.jivesoftware.smack.util.DNSUtil.resolveDomain(DNSUtil.java:209)
at org.jivesoftware.smack.util.DNSUtil.resolveXMPPServiceDomain(DNSUtil.java:136)
at org.jivesoftware.smack.AbstractXMPPConnection.populateHostAddresses(AbstractXMP PConnection.java:626)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPC onnection.java:556)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection. java:888)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.ja va:377)
Thanks to Grigory Fedorov for reporting.
Before this, if there was a stream error response by the server to our
stream open, that error response would only be handled in the reader
thread, and the user would get a message like:
"org.jivesoftware.smack.SmackException$NoResponseException: No
response received within reply timeout. Timeout was
5000ms (~5s). While waiting for SASL mechanisms stream feature from
server"
while the server may actually sent something like
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='6785787028201586334'
from='jabbim.com'
version='1.0'
xml:lang='en'>
<stream:error>
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
</policy-violation>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Too many (2) failed authentications from this IP
address (1xx.66.xx.xxx). The address will be unblocked at 04:24:00
06.01.2017 UTC
</text>
</stream:error>
</stream:stream>
It was necessary to change saslFeatureReceived from SmackException to
XMPPException in order to return the StreamErrorException at this sync
point. But this change in return required the introduction of a
tlsHandled sync point for SmackException (which just acts as a wrapper
for the various exception types that could occurn when establishing
TLS). The tlsHandled sync point is marked successful even if no TLS
was established in case none was required and/or if not supported by
the server.
W/System.err: java.lang.IllegalStateException: Can not perform operation because the DNS resolution was unsuccessful
W/System.err: at de.measite.minidns.hla.ResolverResult.throwIseIfErrorResponse(ResolverResult.ja va:113)
W/System.err: at de.measite.minidns.hla.ResolverResult.getAnswers(ResolverResult.java:56)
W/System.err: at org.jivesoftware.smack.util.dns.minidns.MiniDnsResolver.lookupHostAddress0(Mini DnsResolver.java:130)
W/System.err: at org.jivesoftware.smack.util.dns.DNSResolver.lookupHostAddress(DNSResolver.java: 52)
W/System.err: at org.jivesoftware.smack.AbstractXMPPConnection.populateHostAddresses(AbstractXMP PConnection.java:612)
W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPC onnection.java:555)
W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection. java:885)
W/System.err: at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.ja va:374)
W/System.err: at com.example.bosleo.chatapp.ChatConnection.connect(ChatConnection.java:147)
W/System.err: at com.example.bosleo.chatapp.ChatConnectionService.initConnection(ChatConnectionS ervice.java:82)
W/System.err: at com.example.bosleo.chatapp.ChatConnectionService.access$100(ChatConnectionServi ce.java:20)
W/System.err: at com.example.bosleo.chatapp.ChatConnectionService$1.run(ChatConnectionService.ja va:105)
W/System.err: at java.lang.Thread.run(Thread.java:818)
W/System.err: Caused by: de.measite.minidns.hla.ResolutionUnsuccessfulException: Asking for 192.168.2.128. IN AAAA yielded an error response NX_DOMAIN
W/System.err: at de.measite.minidns.hla.ResolverResult.getResolutionUnsuccessfulException(Resolv erResult.java:89)
W/System.err: at de.measite.minidns.hla.ResolverResult.throwIseIfErrorResponse(ResolverResult.ja va:111)
W/System.err: ... 12 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.charAt(String.java:658)
at org.jivesoftware.smack.util.dns.HostAddress.<init>(HostAddress.java:48)
at org.jivesoftware.smack.util.dns.HostAddress.<init>(HostAddress.java:62)
In previous Smack versions, it was possible to set the host's IP
address via setHost(String), this is no longer possible (since the
support for DNSSEC was introduced). The new
setHostAddress(InetAddress) allows it again to explicitly specifiy the
XMPP service's host IP.
capturing all outoing presences of type 'available' would also capture
presences not used for presence broadcast, e.g., MUC presences.
This caused the EntityCaps integration test (localEntityCaps) to fail
if the MUC integration test was run before.
The pattern
if (now > deadline) break;
wait(deadline - now);
is insufficient in case "now == deadline" because the result would be
wait() being called with 0, which would mean "wait until
notified". Thus, the timeout would become infinite.
the manager must use a copy of the BlockListIQ's JID list, since it may
be the empty list which is not modifiable.
Also rename the getter methods from getJids() to getBlockedJids().
It was a *very* bad idea to perform the SecurityMode.Required check in
the connection's reader thread and not at the end of
AbstractXMPPConnectin's connect(). :/
This behavior dates back to 8e750912a7
Fixes SMACK-739
and not by '!error' as this there are presence stanzas containing the
muc#user namespace also send to the client, which results in a
ClassCastException in the StanzaListener.
It was a *very* bad idea to perform the SecurityMode.Required check in
the connection's reader thread and not at the end of
AbstractXMPPConnectin's connect(). :/
This behavior dates back to 8e750912a7
Fixes SMACK-739
Returning a boolean is not really expressive in such cases. For example,
if it returns 'false' then the callee has no information *what* went
wrong. Instead throw an SmackException with some more information.
This adds supports for an experimental protocol flow where a pending
friend request's decission is later on deliverd to the requestor after
the owner made its decission.
as otherwhise the following could happen:
WARNING: Connection XMPPTCPConnection[not-authenticated] (0) closed with error
java.security.KeyStoreException: Uninitialized keystore
at java.security.KeyStore.aliases(KeyStore.java:1233)
at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:127)
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:739)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000(XMPPTCPConnection.java:146)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1026)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:960)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:975)
at java.lang.Thread.run(Thread.java:745)
org.jivesoftware.smack.SmackException: java.security.KeyStoreException: Uninitialized keystore
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1033)
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:960)
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:975)
java.lang.Thread.run(Thread.java:745)
java.security.KeyStoreException: Uninitialized keystore
java.security.KeyStore.aliases(KeyStore.java:1233)
sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:127)
sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:739)
org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000(XMPPTCPConnection.java:146)
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1026)
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:960)
org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:975)
java.lang.Thread.run(Thread.java:745)
Because of the condition "c >= 32", Smack would possible return a
c-nonce containing ASCII whitespace characters (32d, 0x20), which are
not allowed in the c-nonce as per RFC 5802.
This commit applies the correct condition: "c > 32".
Fixes SMACK-735.
A unauthorized user sents a update room subject message which is
rejected by the server. It responds with an error message which
is not picked up by the ChangeSubjectListener.
Mostly remove the helper utils. The server is required to present the
client with a consisent state of the block list and corresponding
modifications, so we should not end up with duplicate entires if we
don't check for them.
SMACK-731
allow multiple of them to be installed, instead of at most one. Fixes
deadlock in LowLevelRosterIntegration test because
IoTProvisioningManager's SubscribeListener would not come up with a
decission.
Smack's previous entity caps implementation assumed that an entity lost
its entity caps feature as soon as a presence without caps from that
entity was received. But according to XEP-0115 § 8.4, this is a
perfectly normal optimization technique. We now reset the caps state
after an available presence becomes unavailable.
Also introduce PresenceEventListener, which is required for this
feature.
Also make Roster.preApprove() take a BareJid as argument.
Fixes SMACK-723.
Some servers respond to disco#info requests with
<iq id='npGtO-21' type='result' to='phone@xxx/MAXS' from='xxx'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity type='pep' name='Prosody' category='pubsub'/>
<identity type='im' name='Prosody' category='server'/>
<feature var='urn:xmpp:blocking'/>
<feature var='urn:xmpp:carbons:2'/>
<feature var='urn:xmpp:carbons:1'/>
<feature var='vcard-temp'/>
<feature var='http://jabber.org/protocol/commands'/>
<feature var='urn:xmpp:mam:0'/>
<feature var='jabber:iq:private'/>
<feature var='http://jabber.org/protocol/pubsub#publish'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='urn:xmpp:ping'/>
<feature var='msgoffline'/>
<feature var='jabber:iq:roster'/>
<feature var='urn:xmpp:archive:auto'/>
<feature var='urn:xmpp:archive:manage'/>
<feature var='urn:xmpp:archive:pref'/>
<feature var='http://jabber.org/protocol/rsm'/>
<feature xmlns='urn:xmpp:archive'><optional><default/></optional></feature>
</query></iq>
Note the
<feature
xmlns='urn:xmpp:archive'><optional><default/></optional></feature>
which will cause the current parser implementation to parse it as
DiscoInfo Feature resulting in an Exception because some attributes are
missing.
This commit prevents this.
in order to improve support for Tor connections.
This makes it possible to establish a connection to an .onion domain by
manually setting host and port in the ConnectionConfiguration and
configuring a Socks5Proxy pointing to a Tor node.
Fixes SMACK-720.
As otherwise the Roster would be still unitialized after a SM resumption
if the connection was uncleanly terminated.
Thanks to Grigory Fedorov for reporting this.
The problem caused by opening input/ output stream before setting ssl
parameters to SSLSession and fixed by changing order of this operations.
Fixes SMACK-712.
Minor-Modifications-By: Florian Schmaus <flo@geekplace.eu>
The previously used approach of
project(':smack-core').sourceSets.test.runtimeClasspath
caused the 'eclipse' target to produce duplicate classpath entries in
.classpath when run with Gradle >= 2.6. It also relied on Gradle
internals.
Instead we now use
project(path: ":smack-core", configuration: "testRuntime")
project(path: ":smack-core", configuration: "archives")
to be able to use test classes from other subprojects (usually
smack-core) in e.g. smack-extensions. The 'archives' configuration
includes the test jar.
See also https://discuss.gradle.org/t/11784
Thanks to Lari Hotari for helping with this issue.
So that we can wrap the original exception within the
SmackException. It's not possible to wrap it into the IOException
because of the used min Android API level.
The method was changed in c6594aec2f, but
this change causes issues if Smack is used on Android *without* a custom
SSLContext:
Caused by: java.security.KeyStoreException: java.security.NoSuchAlgorithmException: KeyStore jks implementation not found
at java.security.KeyStore.getInstance(KeyStore.java:119)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:697)
Caused by: java.security.NoSuchAlgorithmException: KeyManagerFactory SunX509 implementation not found
at org.apache.harmony.security.fortress.Engine.notFound(Engine.java:177)
at org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:151)
at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:77)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:708)
Don't log the exception for now because the stack trace makes to much
noise in the log output. This is mostly caused by Googles outdated
Entity Capabilities implementation.
instead of feature-not-implemented.
Changes to send service-unavailable for not handled iq as said in
RFC6120 § 8.4: https://tools.ietf.org/html/rfc6120#page-128
"""
o If an intended recipient receives an IQ stanza of type "get" or
"set" containing a child element qualified by a namespace it does
not understand, then the entity MUST return an IQ stanza of type
"error" with an error condition of <service-unavailable/>.
"""
bareJidChats is a ConcurrentHashMap which does not allow 'null' keys,
thus get(null) returns a NPE. And asEntityBareJidIfPossible may return
'null', this could happen.
replaces DefaultExtensionElement which is now deprecated.
Also changes Stanza (and MultiMap) API so that there can be duplicate extension
elements, as this change is required for StandardExtensionElement and by
the XMPP standard.
This can happen for example if the store schema changes across Smack
version.
Previously Smack would simply ignore the entry, which would lead to an
inconsistent view of the Roster.
remove (set|get)ItemStatus. This was always the ask status, which can
only be set to 'subscribe' or is non-existent.
Use the standard (de-)serialization facilities for DirectoryRosterStore.
Fixes Smack-657.
This adds the ability to provide a distinct authorization identifier for use
by SASL mechanisms. Not all SASL mechanisms support this operation, in
particular CRAM-MD5.
Both the javax and provided SASL implementations are extended, and an authzid
parameter added to the authenticate method.
The authorization identifier is passed as a EntityBareJid in order to assure the
correct form.
Resolves SMACK-677.
Minor-Modifications-By: Florian Schmaus <flo@geekplace.eu>
instead of String, which will always return null if used with
ocupantsMap.get(String), because String.equals(Object) is only true if
Object is also instanceof String.
Thanks to Adnan Elezovic for reporting.
And replace all instances where String.Builder.append() is called with a
String of length one with append(char).
Also adds StringUtils.toStringBuilder(Collection, String).
Instead of extending SocketFactory, the proxy support classes now
implement ProxySocketConnection. This removes a lot of unnecessary
code.
Also re-enables proxy support, which was broken in previous versions
because none of extended SocketFactories did override
createSocket() (SMACK-683).
if the connection is not connected in sendStanzaWithResponseCallback and
in PacketCollector.
Also decrease log level if roster result listener's exeption callback is
invoked with a NotConnectedException.
A sequence of connect(), disconnect(), and connect() could cause the
connection to get disconnected again by the old reader thread, which was
blocking on disconnect because a closing stream tag was read. If the
second connect() was processed before the disconnect(), then the
connectin would get disconnected right after the second connect().
This showed up as a "strange" sequence of stanzas in the XMPP servers
log. Note that the stanza ID of the unavailable presence has a lower
number then the previous stanzas:
Jun 11 23:11:11 c2s18c2370 debug Resource bound: smack-inttest-two-93t70@geekplace.eu/two-93t70
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <iq id='qn03S-26' type='get'>
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <presence id='qn03S-27'>
Jun 11 23:11:11 c2s18c2370 debug Received[c2s]: <presence id='qn03S-23' type='unavailable'>
Jun 11 23:11:11 c2s18c2370 debug Received </stream:stream>
This is because the disconnect() of the first reader thread could
generate the unavailable presence, but was blocked afterwards when
entering the synchronized disconnect(Presence unavailablePresence).
SMACK-633.
If such an exception ever happes when running a integration, then the
framework should not abort, but instead log the exception so that other
information is also logged.
Make Roster entries Map from BareJid to RosterEntry, since only
bare JIDs are allowed as roster items as per RFC 6121 § 3.1.1
When a user sends a presence subscription request to a potential
instant messaging and presence contact, the value of the 'to'
attribute MUST be a bare JID <contact@domainpart> rather than a full
JID <contact@domainpart/resourcepart>,…
Also some further Roster API changes regarding JIDs.
Instead of allocating one big continuous memory block before "writing"
the XMPP stream element to the socket, write the single CharSequences of
LazyStringBuilder/XmlStringBuilder.
Also change Obserable writer to only notify the listeners after a
flush *or* if a certain limit has been reached since the last
notification. Otherwise the debugger would "print" every single XML part
as result of this change.
Add
- performSaslAnonymousAuthentication()
- performSaslExternalAuthentication(SSLContext)
- addEnabledSaslMechanism(String)
- addEnabledSaslMechanisms(Collection<String>)
to ConnectionConfiguration.Builder.
Instead of providing a special API call for anonymous authentication,
Smack now has a configuration builder method to set anonymous/external
authentication. This also removes a lot of duplicate code within
Smack.
Also move SASLAnonymous into o.j.smack.sasl.core.
Fixes SMACK-629.
Also add MucConfigFormManager and improve the MUC API (SMACK-648). Bump
to jxmpp 0.5.0-alpha3.
Improve and extend PrivateDataManager and BookmarkManager.
as otherwhise the reflective invokation will eventually throw an
Exception like
Exception in thread "main" java.lang.NullPointerException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runTests(SmackIntegrationTestFramework.java:412)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.run(SmackIntegrationTestFramework.java:163)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.main(SmackIntegrationTestFramework.java:89)
:smack-integration-test:run FAILED
XEP-0080 states that lon,lat,error,alt,accuracy,bearing and speed are
decimal values, and thus should either be present as decimal, or not present
at all (as they are optional elements).
Usage of String.valueOf(value) in code lead to creating a "null"
string in case number was not present, thus creating an element with
"null" content, which is not a valid decimal value.
Remove the TestSuite class. We now have
SmackTestSuite
^
|
InitExtensions
^
|
$UnitTest
where most basic setup is done in a static block within
SmackTestSuite (only stringencoder setup right now).
Also some minor fixes in unit tests.
We now treat warnings as errors (-Werror).
In order to do so, it was necessary to remove Java7HostnameVerifier
since it depended on internal properietary API. XmppHostnameVerifier
take the place of it.
- Lines containing tab(s) after space
- Usage of printStackTrace
- Usage of println
- Add SupressionCommentFilter module
SuppressionCommentFilter can be enabled with
// CHECKSTYLE:OFF
and disabled with
// CHECKSTYLE:ON
instead of throwing XmlPullParserException, IOException and
SmackException.
Add a guard to AbstractXMPPConnection.processPacket() to always re-throw
RuntimeExceptions.
with the correct parameters to collect the jacocoReports from all
subprojects and put the jacocoTestReport.xml in the right place, so that
the coveralls plugin is able to find it.
- Made jid of type BareJid
- Made it implement TypedCloneable
- Made it implement Serializable
- Made it immutable
Also update its parsing code. And add some convenience methods to
ParserUtils.
* run `gradle check` successfully in order to make sure that your code does not break any JUnit tests and is conform to the projects code style.
* (if applicable) mention any Jira issue codes (eg. `SMACK-XXX`) in the *body* of your commit message (not the header), so that Jira automatically links the PR to the issue.
d="m 351.001,359.31 c -17.234,-7.3 -51.945,15.909 -51.945,15.909 l 0,0 c 0,0 31.115,-33.702 27.068,-47.102 l 0,0 c -4.048,-13.401 -44.827,-30.694 -44.827,-30.694 l 0,0 c 0,0 51.173,5.823 53.705,-8.205 l 0,0 c 2.528,-14.031 -3.951,-54.186 -3.951,-54.186 l 0,0 c 0,0 25.887,37.471 39.897,36.872 l 0,0 c 14.012,-0.597 39.902,-36.872 39.902,-36.872 l 0,0 c 0,0 -14.178,43.955 -3.952,54.186 l 0,0 c 10.225,10.229 53.706,8.205 53.706,8.205 l 0,0 c 0,0 -43.02,12.932 -44.827,30.694 l 0,0 c -1.81,17.759 27.07,47.102 27.07,47.102 l 0,0 c 0,0 -35.718,-23.04 -51.948,-15.909 l 0,0 c -16.232,7.13 -19.951,50.533 -19.951,50.533 l 0,0 c 0,0 -2.718,-43.232 -19.947,-50.533"
d="m 351.001,359.31 c -17.234,-7.3 -51.945,15.909 -51.945,15.909 l 0,0 c 0,0 31.115,-33.702 27.068,-47.102 l 0,0 c -4.048,-13.401 -44.827,-30.694 -44.827,-30.694 l 0,0 c 0,0 51.173,5.823 53.705,-8.205 l 0,0 c 2.528,-14.031 -3.951,-54.186 -3.951,-54.186 l 0,0 c 0,0 25.887,37.471 39.897,36.872 l 0,0 c 14.012,-0.597 39.902,-36.872 39.902,-36.872 l 0,0 c 0,0 -14.178,43.955 -3.952,54.186 l 0,0 c 10.225,10.229 53.706,8.205 53.706,8.205 l 0,0 c 0,0 -43.02,12.932 -44.827,30.694 l 0,0 c -1.81,17.759 27.07,47.102 27.07,47.102 l 0,0 c 0,0 -35.718,-23.04 -51.948,-15.909 l 0,0 c -16.232,7.13 -19.951,50.533 -19.951,50.533 l 0,0 c 0,0 -2.718,-43.232 -19.947,-50.533"
Import IDE settings from `./resources/eclipse/` to configure proper ordering of imports and correct formatting that should pass the CheckStyle rules.
### IntelliJ IDEA
Import Java Code Style settings from `./resources/intellij/smack_formatter.xml` to configure import optimisation and code formatting to pass the CheckStyle rules when building or submitting PRs.
_We've noticed, at time of writing, that IntelliJ often requires a restart when applying new rules - no amount of OK/Apply will do the trick._
# Smack Providers
Providers are responsible for parsing the XMPP XML stream into new Java objects.
## Provider Design
Assume you want to parse the following stanza extension element
```xml
<myExtensionattrFoo='fourthyTwo'>
<myElement>Foo is greater then Bar</myElement>
<myInfoalpha='true'delta='-1337'/>
</myExtension>
```
then the related provider would look like this
```java
public MyExtension parse(XmlPullParser parser, int initialDepth) {
int delta = ParserUtils.getIntegerAttribute(parser, "delta");
myInfo = new MyInfo(alpha, delta);
break;
}
break;
case END_ELEMENT:
// The abort condition with the break labeled loop statement
if (parser.getDepth() == initialDepth) {
break outerloop;
}
break;
default:
// Catch all for incomplete switch (MissingCasesInEnumSwitch) statement.
break;
}
}
// Create the actual class at the very end, design the classes as immutable as possible
return new MyExtension(attrFoo, myElement, myInfo);
}
```
## Common Pitfalls
Use a `long` instead of `int` when the XML schema says `xs:unsignedInt`, because Java's `int` range is to small for this XML numeric data type.
# Stanzas
## General Rules
All classes which subclass `TopLevelStreamElement` and `ExtensionElement` must either
1. be immutable (and ideally provide a Builder)
2. implement `TypedCloneable`
and must be `Serializable`.
The reason that it must be either 1. or 2. is that it makes no sense to clone an inmutable instance.
The preferred option is 1.
Note that there is legacy code in Smack which does not follow these rules. Patches are welcome.
## ExtensionElement
Extension elements are XML elements that are used in various parts and levels of stanzas.
## The static `from(Stanza)` Method
Every ExtensionElement class must have a static `from()` method that retrieves that extension for a given Stanza (if any).
Sample Code
```java
public static RSMSet from(Stanza) {
return packet.getExtension(ELEMENT, NAMESPACE);
}
```
Sometimes certain ExtensionElement's are only found in one stanza type, in that case, specify the parameter type. For example `public static CarbonExtension getFrom(Message)`.
[Smack] is an Open Source, cross-platform, easy to use Java XMPP
client library.
[Smack] is an open-source, highly modular, easy to use, XMPP client library written in Java for Java SE compatible JVMs and Android.
[Smack] is an Open Source [XMPP (Jabber)] client library for instant
messaging and presence. A pure Java library, it can be embedded into
your applications to create anything from a full XMPP client to simple
XMPP integrations such as sending notification messages and
presence-enabling devices.
Being a pure Java library, it can be embedded into your applications to create anything from a full XMPP instant messaging client to simple XMPP integrations such as sending notification messages and presence-enabling devices.
Smack and XMPP allow you to easily exchange data in various ways e.g., fire-and-forget, publish-subscribe, between human and non-human endpoints (M2M, IoT, …).
Confused? Have a look at the [Overview](documentation/overview.md).
More information is provided by the [Overview](documentation/overview.md).
[Smack] - an [Ignite Realtime] community project.
Getting started
---------------
Start with having a look at the **[Documentation]** and the **[Javadoc]**.
Instructions on how to use Smack in your Java or Android project are provided in the [Smack Readme and Upgrade Guide](https://igniterealtime.org/projects/smack/readme).
License
-------
Most of Smack is governed by the Apache License 2.0 (SPDX License Identifier: Apache 2.0). This license requires that the contents of a NOTICE text file are shown "…within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.".
Smack comes which such a NOTICE file. Moreover, since `smack-core` is licensed under the Apache License 2.0, the conditions apply to every project using Smack. The content of Smack's NOTICE file can conveniently be retrieved using `Smack.getNoticeStream()`.
Some subprojects of Smack are governed by other licenses. Please refer to the individual subprojects.
Professional Services
---------------------
Smack is a collaborative effort of many people.
Some are paid, e.g., by their employer or a third party, for their contributions.
But many contribute in their spare time for free.
While we try to provide the best possible XMPP library for Android and Java SE-compatible execution environments by following state-of-the-art software engineering practices, the API may not always perfectly fit your requirements.
Hence welcome contributions and encourage discussion about how Smack can be further improved.
We also provide **paid services** ranging from **XMPP/Smack related consulting** to **designing and developing features** to accommodate your needs.
Please contact [Florian Schmaus](mailto:flo@geekplace.eu) for further information.
Bug Reporting
-------------
Only a few users have access for for filling bugs in the tracker. New
Only a few users have access for filling bugs in the tracker. New
users should:
1. [Create a forums account](https://community.igniterealtime.org/login!input.jspa?registerOnly=true) (only e-mail is a requirement, you can skip all the other fields).
2. Login to the forum account
3. Press New in your toolbar and choose Discussion
4. Choose the [Smack Developers Forum] of Smack and add the tag 'bug_report' to your new post
1. Read ["How to ask for help or report an issue"](https://github.com/igniterealtime/Smack/wiki/How-to-ask-for-help,-report-an-issue-and-possible-solve-the-problem-yourself)
2. [Create a discourse account](https://discourse.igniterealtime.org/signup) (you can also sign up with your Google account).
3. Login to the forum account
4. Press "New Topic" in your toolbar and choose the 'Smack Support' sub-category.
Please search for your issues in the bug tracker before reporting.
Contact
-------
The developers hang around in `#smack` (freenode, IRC) and `open_chat@conference.igniterealtime.org` (XMPP MUC room).
The developers hang around in [smack@conference.igniterealtime.org](xmpp:smack@conference.igniterealtime.org?join). You may use [this link](https://inverse.chat/badge.svg?room=smack@conference.igniterealtime.org) to join the room via [inverse.chat](https://inverse.chat).
Remember that it may take some time (~hours) to get a response.
You can also reach us via the [Smack Users Forum] if you have questions or need support, or the [Smack Developers Forum] if you want to discuss Smack development.
You can also reach us via the [Smack Support Forum] if you have questions or need support, or the [Smack Developers Forum] if you want to discuss Smack development.
Contributing
------------
If you want to start developing for Smack and eventually contribute code back, then please have a look at the [Guidelines for Smack Developers and Contributors](https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors).
The guidelines also contain development quickstart instructions.
[Ignite Realtime] is an Open Source community composed of end-users and developers around the world who
are interested in applying innovative, open-standards-based Real Time Collaboration to their businesses and organizations.
[Ignite Realtime] is an Open Source community composed of end-users and developers around the world who are interested in applying innovative, open-standards-based RealTime Collaboration to their businesses and organizations.
We're aimed at disrupting proprietary, non-open standards-based systems and invite you to participate in what's already one
of the biggest and most active Open Source communities.
<propertyname="message"value="Don't use StringBuilder.append(String) when you can use StringBuilder.append(char). Solution: Replace double quotes of append's argument with single quotes."/>
</module>
<modulename="FileTabCharacter"/>
<modulename="RegexpSingleline">
<!--
Explaining the following Regex
\s+ $
| +- End of Line (2)
+- At least one whitespace (1)
Rationale:
Matches trailing whitespace (2) in lines containing at least one (1) non-whitespace character
<propertyname="message"value="Comment start ('//') followed by non-space character. You would not continue after a punctuation without a space, would you?"/>
</module>
<!-- Check for synchronized keyword on Manager's static
getInstanceFor() method. Note that if XMPPConnection is every
replaced with something else, then we need to change it here
<propertyname="message"value="Usage Boolean.valueOf(), consider using ParserUtils.parseXmlBoolean() instead (if you want to parse xs:boolean values)"/>
<propertyname="ignoreComments"value="true"/>
</module>
<modulename="RegexpSinglelineJava">
<propertyname="format"value="^\t+"/>
<propertyname="message"value="Indent must not use tab characters. Use space instead."/>
</module>
<modulename="JavadocMethod">
<!-- TODO stricten those checks -->
<propertyname="scope"value="protected"/>
</module>
<modulename="JavadocStyle">
<propertyname="scope"value="public"/>
<propertyname="checkEmptyJavadoc"value="true"/>
<propertyname="checkHtml"value="false"/>
</module>
<modulename="ParenPad">
</module>
<modulename="NoWhitespaceAfter">
<propertyname="tokens"value="INC
, DEC
, UNARY_MINUS
, UNARY_PLUS
, BNOT, LNOT
, DOT
, ARRAY_DECLARATOR
, INDEX_OP
"/>
</module>
<modulename="WhitespaceAfter">
<propertyname="tokens"value="TYPECAST
, LITERAL_IF
, LITERAL_ELSE
, LITERAL_WHILE
, LITERAL_DO
, LITERAL_FOR
, DO_WHILE
, COMMA
"/>
</module>
<modulename="WhitespaceAround">
<property
name="ignoreEnhancedForColon"
value="false"
/>
<!-- Currently disabled tokens: LCURLY, RCURLY, WILDCARD_TYPE, GENERIC_START, GENERIC_END -->
The `org.jivesoftware.smack.XMPPConnection` class manages your connection to
an XMPP server. The default implementation is the
`org.jivesoftware.smack.XMPPTCPConnection` class. Two constructors are mainly
used. The first, `XMPPTCPConnection(String)` takes the server name you'd like
to connect to as an argument. All default connection settings will be used:
* A DNS SRV lookup will be performed to find the exact address and port (typically 5222) that the server resides at.
* The maximum security possible will be negotiated with the server, including TLS encryption, but the connection will fall back to lower security settings if necessary.
* The XMPP resource name "Smack" will be used for the connection.
Alternatively, you can use the `XMPPTCPConnection(ConnectionConfiguration)`
constructor to specify advanced connection settings. Some of these settings
include:
* Manually specify the server address and port of the server rather than using a DNS SRV lookup.
* Enable connection compression.
* Customize security settings, such as flagging the connection to require TLS encryption in order to connect.
* Specify a custom connection resource name such as "Work" or "Home". Every connection by a user to a server must have a unique resource name. For the user "jsmith@example.com", the full address with resource might be "jsmith@example.com/Smack". With unique resource names, a user can be logged into the server from multiple locations at once, or using multiple devices. The presence priority value used with each resource will determine which particular connection receives messages to the bare address ("jsmith@example.com" in our example).
Connect and Disconnect
----------------------
```
// Create the configuration for this new connection
Smack includes two built-in debugging consoles that will let you track
all XML traffic between the client and server. A lite debugger and an
enhanced debugger contained in `smack-debug.jar`, and a console debugger in `smack-core.jar`.
Debugging mode can be enabled in two different ways:
1. Add the following line of code **before** creating new connections:
`SmackConfiguration.DEBUG = true;`
2. Set the Java system property `smack.debugEnabled` to true. The system property can be set on the command line such as:
`java -Dsmack.debugEnabled=true SomeApp `
If you wish to explicitly disable debug mode in your application, including
using the command-line parameter, add the following line to your application
before opening new connections:
`SmackConfiguration.DEBUG = false;`
Smack uses the following logic to decide the debugger console to use:
1. It will first try use the debugger class specified in the Java system property `smack.debuggerClass`. If you need to develop your own debugger, implement the `SmackDebugger` interface and then set the system property on the command line such as:
2. If step 1 fails then Smack will try to use the enhanced debugger. The file `smackx-debug.jar` contains the enhanced debugger. Therefore you will need to place the jar file in the classpath. For situations where space is an issue you may want to only deploy `smack-core.jar` in which case the enhanced and lite debugger won't be available, but only the console debugger.
3. The last option if the previous two steps fail is to use the console debugger. The console debugger is a very good option for situations where you need to have low memory footprint.
Enhanced Debugger
-----------------
 When debugging mode is
enabled, a debug window will appear containing tabs for each new created
connection. The window will contain the following information:
* XMPPConnection tabs -- each tab shows debugging information related to the connection.
* Smack info tab -- shows information about Smack (e.g. Smack version, installed components, etc.). The connection tab will contain the following information:
* All Stanzas -- shows sent and received packets information parsed by Smack.
* Raw Sent Stanzas -- raw XML traffic generated by Smack and sent to the server.
* Raw Received Stanzas -- raw XML traffic sent by the server to the client.
* Ad-hoc message -- allows to send ad-hoc packets of any type.
* Information -- shows connection state and statistics.
Lite Debugger
-------------
 When debugging mode is enabled, a
debug window will appear when each new connection is created. The window will
contain the following information:
* Client Traffic (red text) -- raw XML traffic generated by Smack and sent to the server.
* Server Traffic (blue text) -- raw XML traffic sent by the server to the client.
* Interpreted Stanzas (green text) -- shows XML packets from the server as parsed by Smack. Right click on any of the panes to bring up a menu with the choices to copy of the contents to the system clipboard or to clear the contents of the pane.
Every PacketExtension class must have a static `from()` method that retrieves that extension for a given Stanza (if any).
Sample Code
```java
public static RSMSet from(Stanza) {
return packet.getExtension(ELEMENT, NAMESPACE);
}
```
Sometimes certain PacketExtension's are only found in one stanza type, in that case, specify the parameter type. For example `public static CarbonExtension getFrom(Message)`.
While a file transfer is in progress you may wish to monitor the progress of a
file transfer.
**Usage**
Both the **_IncomingFileTransfer_** and the **_OutgoingFileTransfer_** extend
the **_FileTransfer_** class which provides several methods to monitor how a
file transfer is progressing:
* **getStatus()** - The file transfer can be in several states, negotiating, rejected, canceled, in progress, error, and complete. This method will return which state the file transfer is currently in.
* **getProgress()** - if the status of the file transfer is in progress this method will return a number between 0 and 1, 0 being the transfer has not yet started and 1 being the transfer is complete. It may also return a -1 if the transfer is not in progress.
* **isDone()** - Similar to getProgress() except it returns a _boolean_. If the state is rejected, canceled, error, or complete then true will be returned and false otherwise.
* **getError()** - If there is an error during the file transfer this method will return the type of error that occured. **Examples**
In this example we can see how to monitor a file transfer:
| [Stream Management](streammanagement.md) | [XEP-0198](http://xmpp.org/extensions/xep-0198.html) | Allows active management of an XML Stream between two XMPP entities (stanza acknowledgement, stream resumption). |
Smack Extensions and currently supported XEPs by Smack (smack-extensions)
| [Data Forms](dataforms.md) | [XEP-0004](http://xmpp.org/extensions/xep-0004.html) | Allows to gather data using Forms. |
| Last Activity | [XEP-0012](http://xmpp.org/extensions/xep-0012.html) | Communicating information about the last activity associated with an XMPP entity. |
| Flexible Offline Message Retrieval | [XEP-0013](http://xmpp.org/extensions/xep-0013.html) | Extension for flexible, POP3-like handling of offline messages. |
| [Privacy Lists](privacy.md) | [XEP-0016](http://xmpp.org/extensions/xep-0016.html) | Enabling or disabling communication with other entities. |
| [Service Discovery](disco.md) | [XEP-0030](http://xmpp.org/extensions/xep-0030.html) | Allows to discover services in XMPP entities. |
| Extended Stanza Addressing | [XEP-0033](http://xmpp.org/extensions/xep-0033.html) | Allows to include headers in stanzas in order to specifiy multiple recipients or sub-addresses. |
| [Multi User Chat](muc.md) | [XEP-0045](http://xmpp.org/extensions/xep-0045.html) | Allows configuration of, participation in, and administration of individual text-based conference rooms. |
| In-Band Bytestreams | [XEP-0047](http://xmpp.org/extensions/xep-0047.html) | Enables any two entities to establish a one-to-one bytestream between themselves using plain XMPP. |
| Bookmarks | [XEP-0048](http://xmpp.org/extensions/xep-0048.html) | Bookmarks, for e.g. MUC and web pages. |
| Advanced Message Processing | [XEP-0079](http://xmpp.org/extensions/xep-0079.html) | Enables entities to request, and servers to perform, advanced processing of XMPP message stanzas. |
| XMPP Date Time Profiles | [XEP-0082](http://xmpp.org/extensions/xep-0082.html) | Standardization of Date and Time representation in XMPP. |
| Chat State Notifications | [XEP-0085](http://xmpp.org/extensions/xep-0085.html) | Communicating the status of a user in a chat session. |
| [Time Exchange](time.md) | [XEP-0090](http://xmpp.org/extensions/xep-0090.html) | Allows local time information to be shared between users. |
| Software Version | [XEP-0092](http://xmpp.org/extensions/xep-0092.html) | Retrieve and announce the software application of an XMPP entity. |
| Stream Initation | [XEP-0095](http://xmpp.org/extensions/xep-0095.html) | Initiating a data stream between any two XMPP entities. |
| [SI File Transfer](filetransfer.md) | [XEP-0096](http://xmpp.org/extensions/xep-0096.html) | Transfer files between two users over XMPP. |
| [Entity Capabilities](caps.md) | [XEP-0115](http://xmpp.org/extensions/xep-0115.html) | Broadcasting and dynamic discovery of entity capabilities. |
| Data Forms Validation | [XEP-0122](http://xmpp.org/extensions/xep-0122.html) | Enables an application to specify additional validation guidelines . |
| Stream Compression | [XEP-0138](http://xmpp.org/extensions/xep-0138.html) | Support for optional compression of the XMPP stream.
| Data Forms Layout | [XEP-0141](http://xmpp.org/extensions/xep-0141.html) | Enables an application to specify form layouts. |
| Personal Eventing Protocol | [XEP-0163](http://xmpp.org/extensions/xep-0163.html) | Using the XMPP publish-subscribe protocol to broadcast state change events associated with an XMPP account. |
| Message Delivery Receipts | [XEP-0184](http://xmpp.org/extensions/xep-0184.html) | Extension for message delivery receipts. The sender can request notification that the message has been delivered. |
| XMPP Ping | [XEP-0199](http://xmpp.org/extensions/xep-0199.html) | Sending application-level pings over XML streams.
| Entity Time | [XEP-0202](http://xmpp.org/extensions/xep-0202.html) | Allows entities to communicate their local time |
| Delayed Delivery | [XEP-0203](http://xmpp.org/extensions/xep-0203.html) | Extension for communicating the fact that an XML stanza has been delivered with a delay. |
| XMPP Over BOSH | [XEP-0206](http://xmpp.org/extensions/xep-0206.html) | Use Bidirectional-streams Over Synchronous HTTP (BOSH) to transport XMPP stanzas. |
| Attention | [XEP-0224](http://xmpp.org/extensions/xep-0224.html) | Getting attention of another user. |
| [Group Chat Invitations](invitation.md) | n/a | Send invitations to other users to join a group chat room. |
| [Jive Properties](properties.md) | n/a | TODO |
Experimental Smack Extensions and currently supported XEPs by Smack (smack-experimental)
| Message Carbons | [XEP-0280](http://xmpp.org/extensions/xep-0280.html) | Keep all IM clients for a user engaged in a conversation, by carbon-copy outbound messages to all interested resources.
| [HTTP over XMPP transport](hoxt.md) | [XEP-0332](http://xmpp.org/extensions/xep-0332.html) | Allows to transport HTTP communication over XMPP peer-to-peer networks. |
| JSON Containers | [XEP-0335](http://xmpp.org/extensions/xep-0335.html) | Encapsulation of JSON data within XMPP Stanzas. |
| Google GCM JSON payload | n/a | Semantically the same as XEP-0335: JSON Containers |
| Client State Indication | [XEP-0352](http://xmpp.org/extensions/xep-0352.html) | A way for the client to indicate its active/inactive state. |
Legacy Smack Extensions and currently supported XEPs by Smack (smack-legacy)
The group chat invitation extension is used to invite other users to a
group chat room.
* Inviting Other Users
* Listen for Invitations
**XEP related:** N/A -- this protocol is outdated now that the Multi-User Chat (MUC) XEP is available ([XEP-45](http://www.xmpp.org/extensions/xep-0045.html)). However, most existing clients still use this older protocol. Once MUC support becomes more widespread, this API may be deprecated.
Inviting Other Users
--------------------
To use the GroupChatInvitation packet extension to invite another user to a
group chat room, address a new message to the user and set the room name
appropriately, as in the following code example:
```
Message message = new Message("user@chat.example.com");
Color favoriteColor = (Color)jpe.getProperty("favoriteColor");
// Get an int property. Note that properties are always returned as
// Objects, so we must cast the value to an Integer, then convert
// it to an int._
int favoriteNumber = ((Integer)jpe.getProperty("favoriteNumber")).intValue();
```
For convenience `JivePropertiesManager` contains two helper methods namely
`addProperty(Stanza packet, String name, Object value)` and
`getProperty(Stanza packet, String name)`.
Objects as Properties
---------------------
Using objects as property values is a very powerful and easy way to exchange
data. However, you should keep the following in mind:
* When you send a Java object as a property, only clients running Java will be able to interpret the data. So, consider using a series of primitive values to transfer data instead.
* Objects sent as property values must implement Serialiable. Additionally, both the sender and receiver must have identical versions of the class, or a serialization exception will occur when de-serializing the object.
* Serialized objects can potentially be quite large, which will use more bandwidth and server resources.
XML Format
----------
The current XML format used to send property data is not a standard, so will
likely not be recognized by clients not using Smack. The XML looks like the
- SM resumption failes on prosody when compression in sync flush mode is used with prosody. See [Prosody issue #433](https://code.google.com/p/lxmppd/issues/detail?id=433).
Enabling stream management
------------------------
TODO
Getting notifications about acknowledges stanzas
------------------------------------------------
TODO
Requisting stanza acknowledgements from the server
This document will introduce you to the Smack API and provide an overview of
important classes and concepts.
JAR Files and Requirements
--------------------------
Smack is meant to be easily embedded into any existing Java application. The
library ships as several JAR files to provide more flexibility over which
features applications require:
* `smack-core.jar` -- provides core XMPP functionality. All XMPP features that are part of the XMPP RFCs are included.
* `smack-tcp.jar` -- support for XMPP over TCP. Includes XMPPTCPConnection class, which you usually want to use
* `smack-extensions.jar` -- support for many of the extensions (XEPs) defined by the XMPP Standards Foundation, including multi-user chat, file transfer, user search, etc. The extensions are documented in the [extensions manual](extensions/index.md).
* `smack-experimental.jar` -- support for experimental extensions (XEPs) defined by the XMPP Standards Foundation. The API and functionality of those extensions should be considered as unstable.
* `smack-legacy.jar` -- support for legacy extensions (XEPs) defined by the XMPP Standards Foundation.
* `smack-bosh.jar` -- support for BOSH (XEP-0124). This code should be considered as beta.
* `smack-jingle.jar` -- support for Jingle. This code is old and currenlty unmaintained.
* `smack-resolver-dnsjava.jar` -- support for resolving DNS SRV records with the help of dnsjava. Ideal for platforms that do not support the javax.naming API.
* `smack-resolver-javax.jar` -- support for resolving DNS SRV records with the javax namespace API.
* `smack-debug.jar` -- an enhanced GUI debugger for protocol traffic. It will automatically be used when found in the classpath and when [debugging](debugging.md) is enabled.
Configuration
-------------
Smack has an initialization process that involves 2 phases.
* Initializing system properties - Initializing all the system properties accessible through the class **SmackConfiguration**. These properties are retrieve by the _getXXX_ methods on that class.
* Initializing startup classes - Initializing any classes meant to be active at startup by instantiating the class, and then calling the _initialize_ method on that class if it extends **SmackInitializer**. If it does not extend this interface, then initialization will have to take place in a static block of code which is automatically executed when the class is loaded.
Initialization is accomplished via a configuration file. By default, Smack
will load the one embedded in the Smack jar at _org.jivesoftware.smack/smack-
config.xml_. This particular configuration contains a list of initializer
classes to load. All manager type classes that need to be initialized are
contained in this list of initializers.
Establishing a Connection
-------------------------
The `XMPPTCPConnection` class is used to create a connection to an XMPP
server. Below are code examples for making a connection:
* Doesn't force you to code at the packet level, as other libraries do. Smack provides intelligent higher level constructs such as the `Chat` and `Roster` classes, which let you program more efficiently.
* Does not require that you're familiar with the XMPP XML format, or even that you're familiar with XML.
* Provides easy machine to machine communication. Smack lets you set any number of properties on each message, including properties that are Java objects.
* Open Source under the Apache License, which means you can incorporate Smack into your commercial or non-commercial applications.
About XMPP
----------
XMPP (eXtensible Messaging and Presence Protocol) is an open protocol
standardized by the IETF and supported and extended by the XMPP Standards
Foundation (([http://www.xmpp.org](http://www.xmpp.org)).
How To Use This Documentation
-----------------------------
This documentation assumes that you're already familiar with the main features
of XMPP instant messaging. It's also highly recommended that you open the
Javadoc API guide and use that as a reference while reading through this
Smack provides a flexible framework for processing incoming packets using two
constructs:
* `org.jivesoftware.smack.PacketCollector` -- a class that lets you synchronously wait for new packets.
* `org.jivesoftware.smack.PacketListener` -- an interface for asynchronously notifying you of incoming packets. A packet listener is used for event style programming, while a packet collector has a result queue of packets that you can do polling and blocking operations on. So, a packet listener is useful when you want to take some action whenever a packet happens to come in, while a packet collector is useful when you want to wait for a specific packet to arrive. Packet collectors and listeners can be created using an `XMPPConnection` instance.
The `org.jivesoftware.smack.filter.StanzaFilter` interface determines which
specific packets will be delivered to a `PacketCollector` or `PacketListener`.
Many pre-defined filters can be found in the `org.jivesoftware.smack.filter`
package.
The following code snippet demonstrates registering both a packet collector
and a packet listener:
```
// Create a packet filter to listen for new messages from a particular
// user. We use an AndFilter to combine two other filters._
StanzaFilter filter = new AndFilter(new StanzaTypeFilter(Message.class),
new FromContainsFilter("mary@jivesoftware.com"));
// Assume we've created an XMPPConnection name "connection".
// First, register a packet collector using the filter we created.
The Smack provider architecture is a system for plugging in custom XML parsing
of packet extensions and IQ packets. The standard [Smack
Extensions](extensions/index.md) are built using the provider architecture.
There are two types of providers:
* `IQProvider` -- parses IQ requests into Java objects.
* `Extension Provider` -- parses XML sub-documents attached to packets into PacketExtension instances. By default, Smack only knows how to process a few standard packets and sub-packets that are in a few namespaces such as:
* jabber:iq:auth
* jabber:iq:roster
* jabber:iq:register There are many more IQ types and extensions that are part of XMPP standards, and of course an endless number that can be added as custom extensions. To support this, an extensible parsing mechanism is provided via Smack and user build providers.
Whenever a packet extension is found in a packet, parsing will be
passed to the correct provider. Each provider must implement the
PacketExtensionProvider interface. Each extension provider is
responsible for parsing the raw XML stream, via the
[XML Pull Parser](http://www.xmlpull.org/), to contruct an object.
bean introspection is used to try to automatically set the properties
of the class using the values in the packet extension sub-element.
When no extension provider is registered for an element name and namespace
combination, Smack will store all top-level elements of the sub-packet in the
DefaultPacketExtension object and then attach it to the packet.
Management of these providers is accomplished via the [ProviderManager]()
class. There are multiple ways to add providers to the manager.
* Call addXXProvider methods - You can call the appropriate add methods directly.
```
ProviderManager.addIQProvider("element", "namespace", new MyIQProvider());
ProviderManager.addExtensionProvider("element", "namespace", new MyExtProvider());
```
* Add a loader - You can add a ProviderLoader which will inject a means of loading multiple providers (both types) into the manager. This is the mechanism used by Smack to load from the Smack specific file format (via ProviderFileLoader). Implementers can provide the means to load providers from any source they wish, or simply reuse the ProviderFileLoader to load from their own provider files.
* VM Argument - You can add a provider file via the VM argument _smack.provider.file_. This will load the file at the specified URL during startup when Smack initializes. This also assumes the default configuration, since it requires that the **VmArgInitializer** was part of the startup configuration.
The roster lets you keep track of the availability ("presence") of other
users. A roster also allows you to organize users into groups such as
"Friends" and "Co-workers". Other IM systems refer to the roster as the buddy
list, contact list, etc.
A `Roster` instance is obtained using the `Roster.getInstanceFor(XMPPConnection)` method.
Roster Entries
--------------
Every user in a roster is represented by a RosterEntry, which consists of:
* An XMPP address (e.g. jsmith@example.com).
* A name you've assigned to the user (e.g. "Joe").
* The list of groups in the roster that the entry belongs to. If the roster entry belongs to no groups, it's called an "unfiled entry". The following code snippet prints all entries in the roster:
Rosters and presence use a permissions-based model where users must give
permission before they are added to someone else's roster. This protects a
user's privacy by making sure that only approved users are able to view their
presence information. Therefore, when you add a new roster entry it will be in
a pending state until the other user accepts your request.
If another user requests a presence subscription so they can add you to their
roster, you must accept or reject that request. Smack handles presence
subscription requests in one of three ways:
* Automatically accept all presence subscription requests.
* Automatically reject all presence subscription requests.
* Process presence subscription requests manually. The mode can be set using the `Roster.setSubscriptionMode(Roster.SubscriptionMode)` method. Simple clients normally use one of the automated subscription modes, while full-featured clients should manually process subscription requests and let the end-user accept or reject each request. If using the manual mode, a PacketListener should be registered that listens for Presence packets that have a type of `Presence.Type.subscribe`.
<p>Smack is a library for client-to-server XMPP connections to perform real-time communications and data exchange. This includes, but is not limited to, instant messaging and group chat. More generically speaking, it allows you to easily exchange data in various ways: For example fire-and-forget, publish-subscribe, between human and non-human endpoints. The use cases include M2M, IoT, and many more.</p>
<p>Smack is a pure Java library, open-source and highly modular. It runs on Android and Java SE. The API strives to be easy to use but yet powerful.</p>
<h2>Key Advantages</h2>
Smack is extremely simple to use, yet provides a powerful API. Sending a text message to a user can be accomplished in only a few lines of code.
<pre>{@code
AbstractXMPPConnection connection = new XMPPTCPConnection("mtucker", "password", "jabber.org");
connection.connect().login();
Message message = connection.getStanzaFactory()
.buildMessageStanza()
.to("jsmith@igniterealtime.org")
.setBody("Howdy! How are you?")
.build();
connection.sendStanza(message);
connection.disconnect();
}</pre>
<p>Smack doesn't force you to code at the protcol level of XMPP. The library provides intelligent higher level constructs, often called {@link org.jivesoftware.smack.Manager}, which let you program more efficiently. Other examples of those constructs are the Chat and Roster classes.</p>
<p>Smack comes with APIs for easy machine-to-machine communication. You can set any number of properties on each message, including properties that are Java objects.</p>
<h2>License</h2>
<p>Smack is open-source and most parts are under the Apache License
2.0, which means you can incorporate Smack into your commercial or
non-commercial applications. Some parts of Smack may be under a
different open-source license. Please refer to the individual
subprojects for their license statement.</p>
<p>Note that the Apache License 2.0 requires that the contents of a
NOICE text file are shown "…within a display generated by the
Derivative Works, if and wherever such third-party notices normally
appear.". Smack comes with such a NOTICE file. The content of
Smack's NOTICE file can conveniently be retrieved using
<p>XMPP (eXtensible Messaging and Presence Protocol) is an open protocol standardized by the <ahref="https://ietf.org/">Internet Engineering Task Force (IETF)</a> and supported and extended by the <ahref="https://www.xmpp.org/">XMPP Standards Foundation (XSF)</a>.</p>
<h2>Smack Modules</h2>
<p>Smack is meant to be easily embedded into any existing Java
application. The library ships as several modules to provide more
flexibility over which features applications require.</p>
<ul>
<li>smack-core -- provides core XMPP functionality. All XMPP features that are part of the XMPP RFCs are included.</li>
<li>smack-im -- provides functionality defined in RFC 6121 (XMPP-IM), like the Roster.</li>
<li>{@link org.jivesoftware.smack.tcp smack-tcp} -- support for XMPP over TCP. Includes XMPPTCPConnection class, which you usually want to use</li>
<li>smack-extensions -- support for many of the extensions (XEPs) defined by the XMPP Standards Foundation, including multi-user chat, file transfer, user search, etc. The extensions are documented in the [extensions manual](extensions/index.md).</li>
<li>smack-experimental -- support for experimental extensions (XEPs) defined by the XMPP Standards Foundation. The API and functionality of those extensions should be considered as unstable.</li>
<li>smack-legacy -- support for legacy extensions (XEPs) defined by the XMPP Standards Foundation.
<li>smack-bosh -- support for BOSH (XEP-0124). This code should be considered as beta.</li>
<li>smack-resolver-minidns -- support for resolving DNS SRV records with the help of <ahref="https://minidns.org">MiniDNS</a>. Ideal for platforms that do not support the javax.naming API. Also supports [DNSSEC](dnssec.md) TODO: Fix link.</li>
<li>smack-resolver-dnsjava -- support for resolving DNS SRV records with the help of dnsjava.</li>
<li>smack-resolver-javax -- support for resolving DNS SRV records with the javax namespace API.</li>
<li>smack-debug -- an enhanced GUI debugger for protocol traffic. It will automatically be used when found in the classpath and when [debugging](debugging.md) is enabled.</li>
<p>Smack has an initialization process that involves 2 phases.</p>
<ul>
<li>Initializing system properties - Initializing all the system properties accessible through the class **SmackConfiguration**. These properties are retrieved by the _getXXX_ methods on that class.</li>
<li>Initializing startup classes - Initializing any classes meant to be active at startup by instantiating the class, and then calling the _initialize_ method on that class if it extends **SmackInitializer**. If it does not extend this interface, then initialization will have to take place in a static block of code which is automatically executed when the class is loaded.</li>
</ul>
<p>
Initialization is accomplished via a configuration file.
By default, Smack
will load the one embedded in the Smack jar at _org.jivesoftware.smack/smack-
config.xml_.
This particular configuration contains a list of initializer
classes to load.
All manager type classes that need to be initialized are
d="m 351.001,359.31 c -17.234,-7.3 -51.945,15.909 -51.945,15.909 l 0,0 c 0,0 31.115,-33.702 27.068,-47.102 l 0,0 c -4.048,-13.401 -44.827,-30.694 -44.827,-30.694 l 0,0 c 0,0 51.173,5.823 53.705,-8.205 l 0,0 c 2.528,-14.031 -3.951,-54.186 -3.951,-54.186 l 0,0 c 0,0 25.887,37.471 39.897,36.872 l 0,0 c 14.012,-0.597 39.902,-36.872 39.902,-36.872 l 0,0 c 0,0 -14.178,43.955 -3.952,54.186 l 0,0 c 10.225,10.229 53.706,8.205 53.706,8.205 l 0,0 c 0,0 -43.02,12.932 -44.827,30.694 l 0,0 c -1.81,17.759 27.07,47.102 27.07,47.102 l 0,0 c 0,0 -35.718,-23.04 -51.948,-15.909 l 0,0 c -16.232,7.13 -19.951,50.533 -19.951,50.533 l 0,0 c 0,0 -2.718,-43.232 -19.947,-50.533"
d="m 351.001,359.31 c -17.234,-7.3 -51.945,15.909 -51.945,15.909 l 0,0 c 0,0 31.115,-33.702 27.068,-47.102 l 0,0 c -4.048,-13.401 -44.827,-30.694 -44.827,-30.694 l 0,0 c 0,0 51.173,5.823 53.705,-8.205 l 0,0 c 2.528,-14.031 -3.951,-54.186 -3.951,-54.186 l 0,0 c 0,0 25.887,37.471 39.897,36.872 l 0,0 c 14.012,-0.597 39.902,-36.872 39.902,-36.872 l 0,0 c 0,0 -14.178,43.955 -3.952,54.186 l 0,0 c 10.225,10.229 53.706,8.205 53.706,8.205 l 0,0 c 0,0 -43.02,12.932 -44.827,30.694 l 0,0 c -1.81,17.759 27.07,47.102 27.07,47.102 l 0,0 c 0,0 -35.718,-23.04 -51.948,-15.909 l 0,0 c -16.232,7.13 -19.951,50.533 -19.951,50.533 l 0,0 c 0,0 -2.718,-43.232 -19.947,-50.533"
d="M 0,600 H 800 V 0 H 0 Z" /></clipPath><clipPath
id="clipPath30"
clipPathUnits="userSpaceOnUse"><path
id="path28"
d="m 200.001,337.31 c -17.233,-7.3 -51.946,15.909 -51.946,15.909 v 0 c 0,0 31.116,-33.703 27.069,-47.103 v 0 c -4.048,-13.4 -44.827,-30.694 -44.827,-30.694 v 0 c 0,0 51.174,5.824 53.704,-8.204 v 0 c 2.528,-14.032 -3.951,-54.186 -3.951,-54.186 v 0 c 0,0 25.889,37.471 39.898,36.872 v 0 c 14.012,-0.598 39.902,-36.872 39.902,-36.872 v 0 c 0,0 -14.178,43.955 -3.951,54.186 v 0 c 10.224,10.229 53.705,8.204 53.705,8.204 v 0 c 0,0 -43.02,12.933 -44.827,30.694 v 0 c -1.811,17.761 27.07,47.103 27.07,47.103 v 0 c 0,0 -35.719,-23.04 -51.948,-15.909 v 0 c -16.232,7.131 -19.951,50.532 -19.951,50.532 v 0 c 0,0 -2.719,-43.23 -19.947,-50.532" /></clipPath><radialGradient
d="m 200.001,337.31 c -17.233,-7.3 -51.946,15.909 -51.946,15.909 v 0 c 0,0 31.116,-33.703 27.069,-47.103 v 0 c -4.048,-13.4 -44.827,-30.694 -44.827,-30.694 v 0 c 0,0 51.174,5.824 53.704,-8.204 v 0 c 2.528,-14.032 -3.951,-54.186 -3.951,-54.186 v 0 c 0,0 25.889,37.471 39.898,36.872 v 0 c 14.012,-0.598 39.902,-36.872 39.902,-36.872 v 0 c 0,0 -14.178,43.955 -3.951,54.186 v 0 c 10.224,10.229 53.705,8.204 53.705,8.204 v 0 c 0,0 -43.02,12.933 -44.827,30.694 v 0 c -1.811,17.761 27.07,47.103 27.07,47.103 v 0 c 0,0 -35.719,-23.04 -51.948,-15.909 v 0 c -16.232,7.131 -19.951,50.532 -19.951,50.532 v 0 c 0,0 -2.719,-43.23 -19.947,-50.532" /></g></g></g></g><g
d="M 0,0 C 0,5.716 -0.189,10.495 -0.376,14.615 H 11.71 l 0.562,-6.276 h 0.281 c 1.968,2.999 6.09,7.308 13.868,7.308 5.996,0 10.587,-3.092 12.554,-7.871 h 0.186 c 1.78,2.436 3.749,4.311 5.997,5.622 2.53,1.406 5.342,2.249 8.715,2.249 8.807,0 15.459,-6.185 15.459,-19.865 v -26.98 H 55.464 v 24.827 c 0,6.652 -2.154,10.493 -6.744,10.493 -3.373,0 -5.622,-2.248 -6.653,-4.967 -0.282,-1.028 -0.469,-2.434 -0.469,-3.559 V -31.198 H 27.731 v 25.672 c 0,5.713 -2.06,9.648 -6.652,9.648 -3.653,0 -5.808,-2.81 -6.65,-5.059 -0.47,-1.124 -0.564,-2.436 -0.564,-3.655 V -31.198 H 0 Z" /></g><g
d="m 0,0 c -7.496,0 -13.304,-1.78 -13.304,-7.214 0,-3.653 2.435,-5.433 5.62,-5.433 3.467,0 6.466,2.341 7.403,5.247 C -0.094,-6.652 0,-5.808 0,-4.966 Z m 13.772,-10.587 c 0,-4.308 0.187,-8.525 0.749,-11.054 H 1.686 l -0.843,4.589 H 0.562 c -2.999,-3.654 -7.682,-5.621 -13.118,-5.621 -9.274,0 -14.802,6.746 -14.802,14.054 0,11.898 10.681,17.522 26.89,17.522 v 0.562 c 0,2.434 -1.312,5.901 -8.339,5.901 -4.685,0 -9.65,-1.593 -12.649,-3.374 l -2.623,9.091 c 3.185,1.779 9.463,4.122 17.802,4.122 15.272,0 20.049,-8.995 20.049,-19.768 z" /></g><g
d="m 0,0 h 0.188 c 1.031,1.967 2.155,3.841 3.278,5.526 l 9.276,13.868 H 29.888 L 13.492,0.845 32.23,-26.42 H 14.709 L 3.56,-7.588 0,-12.18 V -26.42 H -14.24 V 40.101 H 0 Z" /></g></g></g></g></svg>
The <tt>smack-core.jar</tt> file in the main distribution folder. The optional
<tt>smack-extensions.jar</tt> contains the <ahref="documentation/extensions/index.html">Smack extensions</a>
while <tt>smack-debug.jar</tt> contains an enhanced debugger.<p>
<p><b>Changelog and Upgrading</b><p>
View the <ahref="changelog.html">changelog</a> for a list of changes since the
last release.
If you are upgrading from Smack 3 to Smack 4, then please consult the <ahref="https://community.igniterealtime.org/docs/DOC-2703">Smack 4 Readme and Upgrade Guide</a>
<p><b>License Agreements</b><p>
<ul>
<li>Use of the Smack source code is governed by the Apache License:
<pre>
Copyright 2002-2008 Jive Software.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</pre></li>
<li>Smack contains icons and images licensed from INCORS GmbH. You are not licensed
to use these icons outside of Smack.</li>
<li>Third-party source code is licensed as noted in their source files.
