James Strachan wrote:
Yeah - I tried to tinker around there but as soon as AMQStateManager is used it pulls in AMQMessage, AMQChannel, MessageStore, QueueRegistry, ExchangeRegistery and pretty much the entire kitchen sink pretty quickly :). So I was wondering if we could put a little plugin a little lower down maybe to keep things as abstract as possible to have things as loosely coupled as possible?
Good point. Queue- and Exchange- Registry are indeed baked into the handler interfaces. A different approach would be needed I think.
(The others you mention are only pulled in by specific handlers which the state manager sets up on initialisation - this was what I was proposing to make more easily pluggable, I did it by subclassing for clustering but admit that was a hack!).
Am thinking if providers are trying to share code, there's not gonna be whole lot of difference between the core part of the protocol in terms of creating connections & channels; its mostly handling the channel commands/methods where different implementations are gonna want to plugin. The more of the basic plumbing code we can reuse (such as validation of the commands and implementing the AMQP processing rules etc) the better.
Agreed.
