PacketReader will be waiting in startup() as long as either:
- the timeout occurs
- notify is called because the last feature stanza was parser
- notify is called because of an exception while parsing
instead of throwing a NoResponseException in case startHandshake()
throws an Exception. The NoResponseException was then thrown when
performing SASL auth, which usually directly followes securing the
connection via TLS (if enabled and provided by the server).
This was causing some trouble, e.g. the maven plugin resolved the
dependency only to artifactId 'core', when it should be
'smack-core'. It was previously working, but likely broke when the
configuration of the subprojects was put into their own build.gradle
files.
SMACK-265
If binding is required or not is told the client by the server within
the features stanzas. Smacks guarantees that connect() blocks until the
features stanzas has been received and processed.
Follow XEP-170 recommendations: Resource binding *after* compression.
Fixes also a bunch of race conditions related to the wait()/notify()
pattern used in the early stages of a Connection where
createPacketCollectorAndSend(Packet).nextResultOrThrow() can not be
used. Those wait()/notify() patterns are currently
- SASL authentication
- compression
- resource binding
Fixes SMACK-454
Fix a race condition in useCompression where the compression request was
send outside the synchronized block, this could cause notify() to be
called without a previoius call to wait().
s/streamCompressionDenied/streamCompressionNegotiationDone/ and re-use
the method once the server ack'd stream compression.
Also don't call notifyConnectionError() when requestStreamCompression()
encounters an exception, instead throw the exception.
Instead of using the connectionID, we now use a new boolean
lastFeaturesParsed to mark when startup() is able to continue or when a
NoResponseException should be thrown.
Fixes the problem when the connectionId was set and the wait() would
timeout, resulting in startup() believing that everything was ok, while
in fact the features where not yet received (or parsed). SMACK-558.
Code for Jive's packet properties should not be in 'core'. Also
de-serializing input from network causes some security implications, it
is therefore disabled as default.
MulitUserChat.create() will throw an SmackException if the MUC service
does not return a 201 status when entering a room. Some MUC
implementations don't return the 201 status but instead behave like
the room already existed.
If the user doesn't care about the room beeing locked until the
initial configuration has been send, he can now use the new
MutliUserChat.createOrJoin(String) method.
Also remove some duplicate code by creating the private enter() method.
Fixes SMACK-557
XMPP Servers should ignore the 'from' attribute of outgoing
stanzas. Makes the behavior how Smack populates the 'from' attribute of
outgoing stanzas configurable. Fixes SMACK-547
This allows us to exploid Java 8 streams and Java 5 for-each
loops. The returned Collections are usually unmodifiable. We decided
against returning Iterable because this would mean determining the
size in O(n) compared to Collection.size() which is often faster
(e.g. O(1)).
This commit renames classes as follows:
* TCPConnection --> XMPPTCPConnection
* BOSHConnection --> XMPPBOSHConnection
There are two reasons for this rename. First, it is there to indicate
that the classes actually _are_ XMPP connections, using different
transport mechanisms. Second, it makes auto-completion in IDEs easier,
the developer can type XMPP<complete> and choose the right backend.
