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.
Those, relatively new, listeners guarantee that the individual
listeners are not invoked in concurrently while preserving the
order. Exactly what MultiUserChat previously did with AsyncButOrdered,
which is now no longer needed and hence can be removed.
Fix a bug in the EqualsBuilder usage in UserTuneElement. Properly
synchronize listeners using CopyOnWriteSet. Make methods and fields
static where sensible and possible. Make
disableUserTuneNotifications() public (why was it private?). And a few
other minor fixes.
This commit will enable user to communicate
information about music to which user is listening.
This feature is less of a requirement and more like fun to me.
An attempt at solving SMACK-257.
Incase you see any chances of improvement,
please let me know :)
The assert on line 659 was causing my build to fail. Two issues caused
gitCommit to be empty.
1. The cmd 'git describe --always --tags --dirty=+' was not given
enough time to complete and had not exited which meant no text in
proc.text
2. The two git commands on lines 653 and 658 were run from the
CWD of my Eclipse IDE, not the $projectDir which caused git to return
an error 128.
To solve the two issues I added a waitForOrKill method call to
proc (like the srCmd had) and I set the execute to run in $projectDir
which I think was the intent/assumption in the original code.
Also add waitFor on git describe command.
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.
