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.
