and use weak references.
Disabling the Socks5Manager every time the connection is terminated, and
re-enabling it when it got connected again causes unwanted side
effects. Like adding a new feature to the ServiceDiscoveryManager causes
an update of the entity's capabilities, which then triggers a new outgoing
presence (announcing the new caps version).
SMACK-671
Also don't override eventually send presences on
updateLocalEntityCaps(), instead save the last sent Presence stanza and
re-send that stanza.
SMACK-669.
Instead of allocating one big continuous memory block before "writing"
the XMPP stream element to the socket, write the single CharSequences of
LazyStringBuilder/XmlStringBuilder.
Also change Obserable writer to only notify the listeners after a
flush *or* if a certain limit has been reached since the last
notification. Otherwise the debugger would "print" every single XML part
as result of this change.
Add
- performSaslAnonymousAuthentication()
- performSaslExternalAuthentication(SSLContext)
- addEnabledSaslMechanism(String)
- addEnabledSaslMechanisms(Collection<String>)
to ConnectionConfiguration.Builder.
Instead of providing a special API call for anonymous authentication,
Smack now has a configuration builder method to set anonymous/external
authentication. This also removes a lot of duplicate code within
Smack.
Also move SASLAnonymous into o.j.smack.sasl.core.
Fixes SMACK-629.
Roster's INSTANCE map has a weak reference to XMPPConnection, which has
a field of RosterEntry(ies), and RosterEntry has a strong reference to
XMPPConnection resulting in a cycle which is preventing XMPPConnection
from getting gc'ed.
SMACK-659.
Must use interceptors instead of sending listeners, as those are
invoked *after* the stanza has been put on the wire. Also use the
correct filter, which excludes ack messages.
Fixes SMACK-656.
Also add MucConfigFormManager and improve the MUC API (SMACK-648). Bump
to jxmpp 0.5.0-alpha3.
Improve and extend PrivateDataManager and BookmarkManager.
The cases where reversed. Change the condition for better readability.
Also fix int and long handling in the computation of
maxResumptionMillies.
Fixes SMACK-654.
as otherwhise SynchronizationPoint may report NoResponseException when
there was in fact a success or failure reported in case there are
multiple threads waiting for the condition.
to prevent a thread from not being notified about a change of the state
of the SynchronizationPoint.
If two threads are waiting for a change, which could happen e.g. because
of a connectivity change and one thread does instantShutdown() while the
other handles connectionClosedOnError(), then only one thread, usually
the one handling connectionClosedOnError(), would be notified and
resumed.
Fixes SMACK-652.
