to avoid
feature-not-implemented
at org.jivesoftware.smack.PacketCollector.nextResultOrThrow(PacketCollector.java:182)
at org.jivesoftware.smack.PacketCollector.nextResultOrThrow(PacketCollector.java:161)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.discoverItems(ServiceDiscoveryManager.java:573)
at org.jivesoftware.smackx.address.MultipleRecipientManager.getMultipleRecipienServiceAddress(MultipleRecipientManager.java:310)
at org.jivesoftware.smackx.address.MultipleRecipientManager.send$7a184d34(MultipleRecipientManager.java:82)
for e.g. Google Apps XMPP services.
This is not to be merged in master/4.1 branch as it already contains a
similar fix.
Similar flaw was also fixed in 2c7f1efe80.
Also ensure that OfflineMessagesManager doesn't leak collector by using
a try/finally block.
Fixes SMACK-592
this was previously erroneously changed with
197548b548 from 'forbidden' to
'not-acceptable'. We now change it back to 'forbidden'.
Also delete FileTransferNegotiator.rejectStream(StreamInitation) because
it is dead code and add some comments and javadoc.
This also marks the starting point for extending the PubSub API to allow
additional packet extensions to be added to the request. This is for
example useful if one wants to limit the result with "Result Set
Management (XEP-59)".
Fixes SMACK-580.
The idea is that xml-roundtrip should *never* be expected from a
XmlPullParser. So what we need is a method that parses the content of an
element without relying on getText() returning text if on START_TAG or
END_TAG. This is already done by PubSubs ItemProvider.
Also add PacketParserUtils.parseElement() which will return the current
element as String and use this method in PubSub's ItemProvider.
by using XmlStringBuilder. Fixes SMACK-577
Also extend LazyStringBuilder with a cache. And extend XmlStringBuilder
with some more convenience methods.
Move the ELEMENT and NAMESPACE definition from Form to DataForm, where
it belongs.
that method never worked correctly since 11 years, ie. the PrivateData
was never added as element text. It's not surprisingly that this was not
discovered in more then a decade, since Smack usually never *sends*
those stanza but only receives them.
But that's no reason to not fix it. :)
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
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.
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.
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
Florian Schmaus