If an roster push with a roster entry without any group is processed,
then the entry is not updated, because unfiledEntries.contains(entry)
would return true, as the RosterEntry.equals() method only compares the
name.
We simply fix it by always removing the entry first and then adding it
again.
Thanks to Christian Schudt for pointing this out.
SMACK-559
Removed some throw declarations from methods, so some try/catch blocks
could be removed.
Use switch/case instead of if/else if.
Make members final when possible.
Add logger statements in case of error IQ result and remove superfluous
check of instanceof IQ.
instead of using the old baseName=smack appendix=project.name approach,
we are now going convention over configuration and renaming the
subprojects directories to the proper name.
Having a prefix is actually very helpful, because the resulting
libraries will be named like the subproject. And a core-4.0.0-rc1.jar is
not as explicit about what it actually *is* as a
smack-core-4.0.0-rc1.jar.
SMACK-265
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)).
