git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9761 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9757 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9755 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9748 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9743 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9741 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9740 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9738 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9736 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9215 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9188 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9186 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9185 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9181 b35dd754-fafc-0310-a699-88a17e54d16e

First stab at replacing Stream Compression with a pluggable system. Note that this commit undoes JM-1059. I'll re-add the fix for that later.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9179 b35dd754-fafc-0310-a699-88a17e54d16e

Bugfix: If a client sends </stream:stream>, the server has to reply with </stream:stream> before it closes the connection. Problem described in http://www.igniterealtime.org/community/thread/27013

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9178 b35dd754-fafc-0310-a699-88a17e54d16e

Added a directory listing service for MUC rooms (jabber:iq:search). Applied the new search to the default MultiUserChatServer implementation, which can act as an example to any other implementation. Added service discovery identity and features to the service that reflect these changes.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9177 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9176 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9174 b35dd754-fafc-0310-a699-88a17e54d16e

Return IQ error internal_server_error when an exception occurs while processing an IQ packet. JM-1125

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9173 b35dd754-fafc-0310-a699-88a17e54d16e

Ignore my last commit. It appears that multiple inheritance is possible, if it concerns interfaces only. That's by far a better solution.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9171 b35dd754-fafc-0310-a699-88a17e54d16e

I'd like MUCRoom to extend another interface (Result). The MUCRoom interface was recently changed to extend the Externalizable interface. As duplicate inheritance in Java isn't an option, I refactored MUCRoom to be an abstract class instead. The classes that implemented MUCRoom didn't seem to extend any other class, that's why I hope I can get away with this. :) Gato, do you agree? I'd like your feedback before I proceed.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9170 b35dd754-fafc-0310-a699-88a17e54d16e

Result Set Management applied to the user search plugin. This effectively enables users to page through a potentially large number of results.

User search wasn't compliant with XEP-0055 in the basic search (invalid search fields were used). I replaced them.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9169 b35dd754-fafc-0310-a699-88a17e54d16e

handleIQ() now validates the features that it adds to responses. It includes the disco#info feature in all responses, and includes the resultsetmanagement feature in all responses that include the disco#items feature.


git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9168 b35dd754-fafc-0310-a699-88a17e54d16e

User now implements the Result interface, to make User objects suited for Result Set Management. Any user listing (the search plugin, for example) will benefit from this.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9167 b35dd754-fafc-0310-a699-88a17e54d16e

Currently, there's an interface defining a DiscoItem object. There's no implementation of it, other than in-line implementations in methods (the same goes for the sub-interface, DiscoServerItem). Where manipulations of DiscoItem objects are done, Dom4J Element instances are used instead. The DiscoItem interface has been replaced by an implementation of that interface (again, same goes for the sub-interface, which is now a subclass). As I assumed there would not be other implementations of the same interface (which would give you 'another kind' of DiscoItem objects, but what's the point?), I removed the interface completely.

As a result of the changed representation, the DiscoItemsProvider interface now declares a method that returns an Iterator of DiscoItem objects, instead of Elements. This caused changes in a number of classes.

Result Set Management functionality has been added, which causes all disco#items request to be result set managable (this is, for instance, useful for large listings or MUC rooms).

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9166 b35dd754-fafc-0310-a699-88a17e54d16e

A new package that defines an interface definition for a 'manageable result' and an interface + default implementation for managing results. The set-up is as such, that it would be easy to implement another manager that does not need the entire resultset to base its calculations on. That can cause significant performance gains for result sets that are resource expensive to acquire or maintain in memory.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9165 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9160 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9154 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9153 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9143 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9139 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9131 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9112 b35dd754-fafc-0310-a699-88a17e54d16e

Disabled packet intercepting altogether in the PEP implementation (means PEP is optimized). Contact Notification Filtering is thus disabled until XEP-0115 is implemented.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9110 b35dd754-fafc-0310-a699-88a17e54d16e

Refactored half of the packet intercepting code to use the newly created RemotePresenceEventListener interface.

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9109 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9108 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9083 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9081 b35dd754-fafc-0310-a699-88a17e54d16e

git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/branches@9062 b35dd754-fafc-0310-a699-88a17e54d16e