On 9/22/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
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!).
:)
Stuff like the Queue/Exchange Registery and MessageStore and the like
could be internal to the handler maybe - handlers typically might want
access to connection or channel local state. If handlers differ on a
per channel basis (e.g. for queues used), it wouldn't be a big deal I
suspect to have a handler object per channel as there are typically
not a monstrous number of channels.
Also if you had a single code generated handler interface with a
method for each of the AMQMethodBody types, you could use the Visitor
pattern to invoke the right method (handler) from the AMQMethodBody
object when the command is read in, avoiding the map lookup in the
AMQStateManager. (We do this in OpenWire too BTW)
Folks would then get a compile error if they forgot to implement some
command. (You might wanna provide an abstract base class with empty
methods for all the methods on the handler interface so folks can
extend from it if they only want to implement partial AMQP support).
--
James
-------
http://radio.weblogs.com/0112098/
