and MultipleRecipient (XEP-33) related code in general (e.g. use
constants where possible).
For getMultipleRecipientServiceAddress() this means that
- the "synchronized (services)" block is removed
- ServiceDiscoveryManager is only retrieved once
The idea that we abstract the scheduling of tasks on Android over this
method turned out to be unnecessary. schedule() was also not really part
of the *public* XMPPConnection API, so it's good that it's gone.
Move some duplicate code from XMPP(TCP|BOSH)Connection to
PacketParserUtils. Remove TestUtils as the method now part of Smack's
public API in PacketParserUtils.
Most importantly, rename reload() method of persistent cache to
"DiscoverInfo lookup(String nodeVer)" and lazily load the data from the
persistent cache to the memory cache.
Smack should not throw an IOException in case a stream got closed by
the remote peer and the user is trying to read() from the stream. This
commit fixes that, by making Smack return '-1' if the stream got
closed by the remote. An IOException will only be thrown if the user
tries to read from a stream that got already closed by *himself*.
SMACK-468
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
Florian Schmaus
Júlio Cesar Bueno Cotta
Jared DiCioccio