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.
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.
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.
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.
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.
