This method was never intended to be part of the public API. It's also
critical that the given Runnables complete within a reasonable
time frame so that they don't block following ones.
If the connection has been reconnected, then we will receive entries
that have been unchanged since the last time we received a roster
result. Without this change, those entries ended up in 'toDelete' and
got deleted.
This change also inlines some roster methods.
Because of OSGi, no subproject of Smack (which is the same as a OSGi
bundle) must export a package that is already exported by another
subproject.
Therefore it was necessary to move the TCP and BOSH code into their own
packages: org.jivesoftware.smack.(tcp|bosh).
OSGi classloader restrictions also made it necessary to create a
Declarative Service for smack-extensions, smack-experimental and
smack-lagacy (i.e. smack subprojects which should be initialized), in
order to initialize them accordingly, as smack-core is, when used in a
OSGi environment, unable to load and initialize classes from other smack
bundles. OSGi's "Service Component Runtime" (SCR) will now take care of
running the initialization code of the particular Smack bundle by
activating its Declarative Service.
That is also the reason why most initialization related method now have an
additional classloader argument.
Note that due the refactoring, some ugly changes in XMPPTCPConnection
and its PacketReader and PacketWriter where necessary.
No code changes. Proofread API docs for Presence.java
Fixed grammar / unclear sentences in some javadocs.
Changed some nouns to be more consistent with API terminology.
Fixed some typos.
as there exists no longer a dependency from smack (now smack-core) to
smackx (now mostly smack-extensions). Therefore this approach is no
longer needed.
SMACK-343
by using a custom ArrayBlockingQueueWithShutdown. Fixes a race condition
where nextpacket() would wait for a notification that would never
arrive, because all all put(Packet) calls are still blocking.
SMACK-560
Right after PacketReader receives the 'success' stanza, indicating
successful SASL authentication, it opens a new stream. The login
process continues in another thread and checks for bindingRequired,
which may not have been set a this point yet.
bindResourceAndEstablishSession() now waits until either the binding
feature stanza is parsed or the default packet timeout occurs.
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.
