qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: A question for the ActiveMQ chaps on the list...
Date Fri, 22 Sep 2006 13:18:51 GMT
On 9/22/06, Gordon Sim <gsim@redhat.com> 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/

Mime
View raw message