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.
