Fix a bug in the EqualsBuilder usage in UserTuneElement. Properly
synchronize listeners using CopyOnWriteSet. Make methods and fields
static where sensible and possible. Make
disableUserTuneNotifications() public (why was it private?). And a few
other minor fixes.
This commit will enable user to communicate
information about music to which user is listening.
This feature is less of a requirement and more like fun to me.
An attempt at solving SMACK-257.
Incase you see any chances of improvement,
please let me know :)
A start for the new Jingle API. Since Jingle is a single IQ with many
plugable extensions, there are some particularities we need to deal
with, e.g. jingle users have to register with JingleManager.
This is untested code. There may be drangons.
Also add MucConfigFormManager and improve the MUC API (SMACK-648). Bump
to jxmpp 0.5.0-alpha3.
Improve and extend PrivateDataManager and BookmarkManager.
add a new AutoReceiptMode enum that specifies how delivery receipt
requests are handled. Default is to send receipts if the requstor is
subscribed to the user's presence.
Also make sure that messages contain an id if a receipt request is
added to it.
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
Data Forms Validation are a part of Data Fields and implemented as
extensions, added to a Datafield.
Data validation extensions are validated before adding to the message,
using the consistency rules as described in the XEP.
Fixes SMACK-621.
Minor modifications done by Florian Schmaus <flo@geekplace.eu>
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.
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.
apply the Manager pattern to 'muc'. This prevents the user creating
multiple MultiUserChat instances for the same MUC.
Move the static method from MultiUserChat to MultiUserChatManager.
Also add AbstractNodeInformationProvider.
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.
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
