We can't always setup the carbons listener in the constructor of the
manager, as the our local XMPP address may not be available yet. So
setup the carbons listener on a connection listener *and* in the
constructor.
This adds supports for an experimental protocol flow where a pending
friend request's decission is later on deliverd to the requestor after
the owner made its decission.
allow multiple of them to be installed, instead of at most one. Fixes
deadlock in LowLevelRosterIntegration test because
IoTProvisioningManager's SubscribeListener would not come up with a
decission.
instead of throwing XmlPullParserException, IOException and
SmackException.
Add a guard to AbstractXMPPConnection.processPacket() to always re-throw
RuntimeExceptions.
Move Forwarded into forward.packet and remove deprecated methods. Also
make fields final.
Improve ForwardedProvider:
- use INSTANCE of DelayInformationProvider
- use loop label
- don't throw exceptions in certain cases, instead log
on package layer instead of Declarative Service (DS) approach.
Restructuring and cleanup of initialization process to ensure that all
internal config files are found by the corresponding bundle
classloaders.
SMACK-343
- HeadersExtension.getHeaders() now returns a List instead of a
Collection
- Use XmlStringBuilder in Header and HeadersExtension toXML()
- Add HeadersProviderTest
- Use Smack formatting
Also remove duplicate parsing code regarding SHIM from HOXT
implementation.
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.
this is the first stop towards fixing "SMACK-65: parsing should look for
depth", by providing the initial parsing depth to the provider. Some
methods (.e.g parseMessage) now use the depth as abort condition,
instead of a unclean String equals check.
parseIQ() and parseExtension() where both renamed to parse.
This also restricts the Exceptions thrown by the parse method, to just
XmlPullParserException, IOException and SmackException (not really a big
victory, but nevertheless a slight improvement).
StreamFeatureProvider is now gone, we simply use PacketExtensionProvider
for stream features.
Adopt to common design patterns in Smack:
- getFrom(Packet) in Packetextensions
- INSTANCES.put() in getInstanceFor()
- ELEMENT instead of ELEMENT_NAME
- Use XmlStringBuilder
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
