Remove the TestSuite class. We now have
SmackTestSuite
^
|
InitExtensions
^
|
$UnitTest
where most basic setup is done in a static block within
SmackTestSuite (only stringencoder setup right now).
Also some minor fixes in unit tests.
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.
Florian Schmaus
Tomáš Havlas
lucastucchi
Ishan Khanna