1
0
Fork 0
mirror of https://github.com/vanitasvitae/Smack.git synced 2024-12-29 05:57:58 +01:00
Commit graph

112 commits

Author SHA1 Message Date
Florian Schmaus
98a3c46e9a Add XMPPConnection.createPacketcollectorAndSend(PacketFilter, Packet)
Using

createPacketCollector(filter);
sendPacket(packet);

was error prone, i.e. the PacketCollector could leak if sendPacket()
would throw an exception and the user forgot to call
PacketCollector.cancel(). For cases where
createPacketCollectorAndSend(IQ) is not sufficient (because we don't
send IQs), createPacketCollectorAndSend(PacketFilter, Packet) is now
used, which does take care that the PacketCollector does not leak if
sendPacket() throws an Exception.
2014-10-13 10:45:00 +02:00
Florian Schmaus
452b2aca0f Add 'PacketParserUtils.addPacketextension()' 2014-10-08 16:01:19 +02:00
Florian Schmaus
6980c8e63d Rework Smack Provider design
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.
2014-10-08 16:01:14 +02:00
Florian Schmaus
5d4aa76d19 Create smack.util.stringencoder for Base64, Base32,…
Use Android's Base64 implementation when on Android, otherwise, when on
Java7, use the existing one.
2014-09-04 11:07:55 +02:00
Florian Schmaus
7277eb553a Enable more 'checkstyle' checks
AvoidStarImport
IllegalImport
RedundantImport
UpperEll
ArrayTypeStyle
GenericWhitespace
EmptyStatement
PackageDelcaration
2014-08-15 23:17:45 +02:00
Vyacheslav Blinov
522d0f30ff Generify Packet class returned by PackageCollector everywhere
This will help to get rid of repetitive class casts, and make
PacketCollector api more inline with itself (since some methods
are already generic return methods).
2014-08-15 12:14:19 +02:00
Florian Schmaus
97b17e83b4 Move "Message Events (XEP-22)" code to legacy
Fixes SMACK-569
2014-07-16 12:01:03 +02:00
Florian Schmaus
f05b208120 Remove some duplicate IQ code
and some dead code in Socks5PacketUtils.
2014-07-04 23:51:00 +02:00
Júlio Cesar Bueno Cotta
9be0c480e3 Change IQ.Type to enum 2014-06-06 21:10:13 -03:00
Florian Schmaus
f67d655fe7 Use jxmpp-core (0.1.0-alpha1-SNAPSHOT)
fixes also SMACK-570, since jxmpp-core's XmppStringUtil contains the fix
for SMACK-570.
2014-06-01 12:24:30 +02:00
Florian Schmaus
4c76f2652d Reworked OSGi support of Smack (SMACK-343)
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.
2014-05-15 16:09:37 +02:00
Florian Schmaus
91fd15ad86 Prefix subprojects with 'smack-'
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
2014-04-28 19:44:14 +02:00