Hey Tristan!
If I understood you correctly, you're suggesting to enhance the ProtocolServer to support multiple EmbeddedCacheManagers (probably with shared transport and by that I mean started on the same Netty server).
Yes, that also could work but I'm not convinced if we won't loose some configuration flexibility.
Let's consider a configuration file -
https://gist.github.com/slaskawi/c85105df571eeb56b12752d7f5777ce9, how for example use authentication for CacheContainer cc1 (and not for cc2) and encryption for cc1 (and not for cc1)? Both are tied to hotrod-connector. I think using this kind of different options makes sense in terms of multi tenancy. And please note that if we start a new Netty server for each CacheContainer - we almost ended up with the router I proposed.
The second argument for using a router is extracting the routing logic into a separate module. Otherwise we would probably end up with several if(isMultiTenent()) statements in Hotrod as well as REST server. Extracting this has also additional advantage that we limit changes in those modules (actually there will be probably 2 changes #1 we should be able to start a ProtocolServer without starting a Netty server (the Router will do it in multi tenant configuration) and #2 collect Netty handlers from ProtocolServer).
To sum it up - the router's implementation seems to be more complicated but in the long run I think it might be worth it.
@Galder - you wrote a huge part of the Hot Rod server - I would love to hear your opinion as well.
Thanks
Sebastian