> I think exploring whether the AMQDestination abstraction could be made a > bit more powerful would be a good thing. E.g. by moving the actions > performed when creating a subscriber or producer into the AMQDestination > subclass rather than having that encoded in the session, producer or > consumer implementations. (I'd need to spend some more time looking at > the code to be more precise on this).
AMQdestination has been designed for JMS that is to say that nothing happens at this level. > That would mean that you could get non-standard behaviour by supplying a > custom subclass as the destination (however you obtained this > destination instance). Though using non-standard destinations would > likely reduce your ability to move between JMS providers, your code > could process streams of messages using only normal JMS interfaces. >From the JMS point of view it may make more sense to extend MessageConsumer and MessageProducer. > i.e. I think the AMQDestination could be enhanced to become a single, > unintrusive extension point that could offer a fair bit of flexibility > and power. Whatever class we extend, nothing prevent us to deliver such a ready to use extension class like for example AMQdestination allowing to add binding keys.
