Hi guys, Re: https://issues.jboss.org/browse/ISPN-3950 The aim here is to enable deployment of custom Hot Rod filter/converter instances to Hot Rod servers running on top of WF, following a similar model to that used for JDBC drivers. I came up with an initial solution in [1] but it’s incomplete because it can only handle a single Hot Rod server definition [2]. Digging through this issue has uncoverered a little can of worms: - It’s possible not only to have N Hot Rod connectors (read: servers) defined in the configuration and they can be added at runtime too via CLI/RHQ. - Deployments of filter/converters can happen anytime, so we’ve enabled Hot Rod servers to be plugged with these at runtime. For the time being, we’ve agreed that if a filter/converter gets deployed, it’ll be applied to all Hot Rod servers. I had an earlier chat with Emmanuel and he suggested having some kind of deployment processor that deals with the filter/converter deployments and registers them in some service. The fun begins now, from my POV, it seems to me that Hot Rod connectors need to depend on the filter/converter deployment tracking service so that if a new Hot Rod connector is added at runtime, it can take all the filter/converter deployments to self. However, the opposite is also plausible, that the filter/converter tracking service depends on all Hot Rod connector services, and that when a filter/converter is deployed, it can be applied to all running Hot Rod servers. This seems like a chicken and egg problem :| What would be the best approach to handle these type of scenarios? Cheers, [1] https://github.com/galderz/infinispan/commit/0a3b37fdab05603654ee81d9ff38... [2] https://github.com/infinispan/infinispan/pull/2742#discussion_r15750154 -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz