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