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.