infinispan/infinispan — pull request #2546 by galderz (2014-05-08 10:50:14+00:00)
Title: ISPN-374 Initial Hot Rod remote events support

* Created, modified and removed events and their expectations with each of the Hot Rod operations.
* Filtered events with optional binary parameters on registration.
* Custom events with optional binary parameters on registration.
* Testing event consumption for distributed and replicated caches with filtering, custom events...etc.
* Initial Java Hot Rod client implementation with support to add and remove listeners, including passing converter and filter factories and support for parameters.
* Server configuration gets a Marshaller configured to be able to unmarshall binary parameters for filter/converter and pass them to the callbacks unserialized.
* This marshaller also used to enable fully typed converter/filter implementations rather than working on binary payloads.

Consider this PR to be 90% complete with the following work still required:
* For server integration, there needs to be a way to deploy these filter/converter factories and their filter/converter instances into the server. This, along with tests that verify that remote events work in server are still TODO.
* The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks. Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured. There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable. However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly. I suspect some users might have similar requirements with their filter/converter instances. I briefly discussed this with @wburns yesterday, but we did not conclude on a particular solution for it. So, for the moment, the marshaller used by these classes is hardcoded.