- No need to use a synchronized map, as the getInstanceFor method is
synchronized
- Put the PingManager in the map where it's created and not in the
constructor
Those were broken since 9e797c1b17 as they
always used the basic PubSub namespace, i.e. without a fragment. Which
resulted in e.g. delete requests look like
<iq to="pubsub.ec-xmpp" id="2GAeW-75" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<delete node="2e92d38c-9e90-47f6-8e26-330d25ebe96b"/>
</pubsub>
</iq>
when the namespace should be in fact
http://jabber.org/protocol/pubsub#owner
Where e.g. entity reference expansion is disbled. Note that this affects
only the VCard provider, as it's the only provider in Smack that uses
SAX's DocumentBuilder.
Fixes SMACK-620
This simplifies code as there is no longer a distinction between
"normal" providers and introspection providers in ProviderManager
necessary.
It's also easier to get an idea where introspection is used for parsing.
- to use CopyOnWriteArraySet for listeners
- do not wrap instance map in sync block (getInstanceFor() is already synchronized)
- use PacketTypeFilter instead of PacketExtensionFilter
- add removeListener(PrivacyListListener)
- rework getPrivacyLists
- don't set from attribute
- remove unused getUser()
Entity Capability versions are useless without the information which
hash algorithm was used to calculate those. Right now, only 'sha-1' is
used, but this may change in the feature. This commit makes the first
steps preparing for such a feature.
Also fixes a minor bug:
- CAPS_CACHE.put(currentCapsVersion, discoverInfo);
currentCapsVersion is not a valid key for the cache, as it does cache
"node + '#' + ver" to disco infos.
Introduce AbstractError, change 'Conditions' to enums. Because of
AbstractError, it was necessary that PlainStreamElement and
TopLevelStreamElement becomes an interface. Thus the implementation of
TopLevelStreamElement.toString() had to be removed.
This adds
- policy-violation
- unexpected-request
to XMPPError.Condition, and removes the
- payment-required
- remote-server-error
- unexpected-condition
- request-timeout
Conditions
The file transfer code does now no longer throw XMPPErrorExceptions, but
SmackExceptions.
Fixes SMACK-608. Makes it possible to resolves SMACK-386.
XEP-141 Data Forms are never used as stand alone packet extension, there
is no need to register the provider with the ProviderManager.
This makes the parse method of DataFormProvider static.
This is actually only part one, i.e. with this commit if the user adds a
PacketExtension to an IQ it will be included in IQ.toXml(). Which was
previously only the case if the IQ subclass explicitly included packet
extensions.
The second part of the change is to change the IQ provider, so that
packet extensions are automatically parsed.
Cases where PacketExtensions are used for Message and IQ are slightly
changed. The IQ sublcass now only has a field with this
PacketExtension (see for example
bytestreams.ibb.packet.DataPacketExtension).
Also changed hoxt API: Removed unnecessary indirection and made the
API more Smack idiomatic.
Thanks to Stefan Karlsson for helping with the implementation.
Also add SASLMechanism.checkIfSuccessfulOrThrow(), to increase the
security by verifying the mechanisms state at the end of SASL
authentication.
SASLMechanism now has a SASLPrep StringTransformer.
Refactor SHA1 functions out of StringUtils into SHA1 utility class.
Add MAC utility class.
Make DummyConnection getSentpacket() methods use generics to make unit
testing SCRAM-SHA1 easier.
Fixes SMACK-398
Make sure that the Packets are of type Message. To prevent:
E/AbstractXMPPConnection﹕ Exception in packet listener
java.lang.ClassCastException: org.jivesoftware.smack.packet.Presence cannot be cast to org.jivesoftware.smack.packet.Message
at org.jivesoftware.smackx.muc.MultiUserChatManager$2.processPacket(MultiUserChatM anager.java:124)
at org.jivesoftware.smack.AbstractXMPPConnection.notifiyReceivedListeners(Abstract XMPPConnection.java:854)
at org.jivesoftware.smack.AbstractXMPPConnection$ListenerNotification.run(Abstract XMPPConnection.java:876)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
at java.util.concurrent.FutureTask.run(FutureTask.java:234)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201 (ScheduledThreadPoolExecutor.java:153)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:267)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:856)
I've got reports from users that in some cases there can be multiple
identities. Not just one, and in this case, the node type may not be the
first identity. We now iterate over all identities until we either found
one of type "leaf" or "collection".
For example one user reports an ejabberd with PEP case, where the first
identity is of type "pep", the second of type "leaf" and a third one
with category "account" and type "registered".
Also extend DiscoverInfo API with hasIdentity(String, String) and
getIdentities(String, String).
in AdHocCommandData.
This check was added in 3a37b71e19, but a
session ID can be null, if it's the first invocation. This prevented
RemoteCommand.execute() from executing, since RemoteCommand's sessionID
member will be null at the first invocation.
