Instead of having the filter/converters plugged with the marshaller instances, it's more practical to have them constructed with the marshaller class, and they can instantiate it in each of the servers. Previous description, for reference, below:

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.

Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.