as otherwhise SynchronizationPoint may report NoResponseException when
there was in fact a success or failure reported in case there are
multiple threads waiting for the condition.
to prevent a thread from not being notified about a change of the state
of the SynchronizationPoint.
If two threads are waiting for a change, which could happen e.g. because
of a connectivity change and one thread does instantShutdown() while the
other handles connectionClosedOnError(), then only one thread, usually
the one handling connectionClosedOnError(), would be notified and
resumed.
Fixes SMACK-652.
We now treat warnings as errors (-Werror).
In order to do so, it was necessary to remove Java7HostnameVerifier
since it depended on internal properietary API. XmppHostnameVerifier
take the place of it.
Until now the reconnection used a fixed policy using random
increasing delay as the number of attempts grows. Even if
that policy is still the default one, it is now possible to
select a fixed delay policy that always waits a fixed amount
of time before trying to reconnect
- Lines containing tab(s) after space
- Usage of printStackTrace
- Usage of println
- Add SupressionCommentFilter module
SuppressionCommentFilter can be enabled with
// CHECKSTYLE:OFF
and disabled with
// CHECKSTYLE:ON
instead of throwing XmlPullParserException, IOException and
SmackException.
Add a guard to AbstractXMPPConnection.processPacket() to always re-throw
RuntimeExceptions.
- Made jid of type BareJid
- Made it implement TypedCloneable
- Made it implement Serializable
- Made it immutable
Also update its parsing code. And add some convenience methods to
ParserUtils.
With bb8dcc9874 the concept if IQ request
handlers was introduced in Smack. This doesn't allow packet/stanza
collectors/listeners to filter for incoming IQ requests. Unfortunately
the file transfer code relied on this being able, so it broke with the
change.
There were two places where the file transfer code was listening for
incoming IQ requests:
- InitationListener(s)
- Negotiator(s)
With this change, we let the InitiationListener signal the existence of
an incoming initation request, send by an IQ of type 'set', using the
newly created EventManager utility.
The negotiator waits for those events to arrive and proceedes as it would
have done when the packet collector was used.
the combination with concurrencyLevel and LinkedBlockingQueue never
worked as intented. The idea was that the cachedExecutorService would
spawn new threads until maximumPoolSize (=concurrencyLevel) is reached,
and then start queing the Runnables.
But this was not the case, since ThreadPoolExecutor does not take into
consideration if the worker threads is busy, i.e. executing a Runnable,
or idle, i.e. waiting for a Runnable.
This means that if a busy Worker would execute a Runnable, which would
block, because it's waiting for an event (e.g. an incoming IQ
request), then the handling of those incoming IQ request would be
queued by ThreadPoolExecutor, because no fewer threads then corePoolSize
are running and the task can be queued (since the LinkedBlockingQueue is
unbounded).
Using the term 'enabled' was a terriable choice from a security
perspective, as it gives the user the impression that the security is
"enabled". In fact this setting is only slightly better then
"disabled".
Make that fact clear in the javadoc too.
The XMPPConnection interface does not define methods to manipulate the
connection state (e.g. connect(), disconnect()). The example should use
the connection type as declared type.
Since e6045c6593 the cached executor
services maximum pool size is limited to concurrencyLevel (was
previously Integer.MAX_VALUE). In order to prevent
RejectExecutionException we need to use an queue which max size is
greater than 1 (i.e. nont an SynchronousQueue).
Connection closed with error java.util.concurrent.RejectedExecutionException: Task org.jivesoftware.smack.tcp.XMPPTCPConnection$2@41dce200 rejected from java.util.concurrent.ThreadPoolExecutor@41d59150[Running, pool size = 3, active threads = 3, queued tasks = 0, completed tasks = 4]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2011)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:793)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1339)
at org.jivesoftware.smack.AbstractXMPPConnection.asyncGo(AbstractXMPPConnection.java:1583)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.processHandledCount(XMPPTCPConnection.java:1655)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$2300(XMPPTCPConnection.java:137)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1083)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPConnection.java:896)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:911)
at java.lang.Thread.run(Thread.java:841)
and remove getConnectionID().
Also make streamId a field of AbstractXMPPConnection. Most XMPP
connection types have a streamId, it appears to be optional when BOSH
is used though.
RFC 6121 § 5.2.2:
"""
If an application receives a message with no 'type' attribute or the
application does not understand the value of the 'type' attribute
provided, it MUST consider the message to be of type "normal" (i.e.,
"normal" is the default).
"""
Otherwise we may get an NPE if the key was cached:
Connection closed with error java.lang.NullPointerException: Attempt to get length of null array
at org.jivesoftware.smack.util.stringencoder.Base64.encodeToString(Base64.java:43)
at org.jivesoftware.smack.sasl.core.SCRAMSHA1Mechanism.evaluateChallenge(SCRAMSHA1Mechanism.java:201)
at org.jivesoftware.smack.sasl.SASLMechanism.challengeReceived(SASLMechanism.java:230)
at org.jivesoftware.smack.SASLAuthentication.challengeReceived(SASLAuthentication.java:328)
at org.jivesoftware.smack.SASLAuthentication.authenticated(SASLAuthentication.java:347)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPConnection.java:894)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:909)
at java.lang.Thread.run(Thread.java:818)
instead of just logging a warning if the XMPP domain has no DNS SRV
lookups, create the failedAddresses list now within DNSUtil and add the
information that the SRV lookup failed.
In initConnection, only initReaderAndWriter() throws IOException.
connectUsingConfiguration doesn't need to take an argument.
PacketReader.init does not throw a SmackException.
Use Async.go() in PacketWriter, just like it's already done in PacketReader.
Also limit the max pool size of the remove callbacks service and use the
same keep alive time for idle threads as the cached executor service
uses.
Note that it would be possible to merge those two. But this could lead
to tasks from the cached executor service blocking the removal of
callbacks, which we don't want.
Make 'order' an long
Parse fall-through case's child elements (message, iq, presence-in,
presence-out)
Remove
privacy.addExtension(new DefaultPacketExtension(parser.getName(), parser.getNamespace()));
at the beginning of PrivacyProvider. Was there since day one for an
unknown reason.
since this method is not only used to determine the key for the
presence map, but also for the 'entries' map.
The logic is in both cases the same: If somehow an entry with an
resourcepart went into the roster (RFC 6121 does not explicity forbid
JIDs with an resourcepart in the roster), then use the full JID as
key, otherwise use the bare JID.
See also SMACK-19.
add a new AutoReceiptMode enum that specifies how delivery receipt
requests are handled. Default is to send receipts if the requstor is
subscribed to the user's presence.
Also make sure that messages contain an id if a receipt request is
added to it.
