On 18/01/2008, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Hi folks, > > I created a separate thread to ensure it gets the attention it deserves. > The javax.jms.Destination provides a very poweful abstraction and we don't > seem to fully utilize it. > The JMS 1.1 introduced the Destination interface bcos they felt the Topic > and Queue didn't cover all the use cases. > Infact the prefered way is to use Destinations and not Topics or Queues. In > the session interface there is no "createDestination" method. > You can only lookup a destination via JNDI. This allows immense flexibility > where you can create any type of destination hidden behind the interface. > > But I see our implementation is centered around Topic and Queues (they are > the first class citizens). > As Gordon pointed out in the BindingURL thread, we can use the Destination > abstraction to cover a lot of the AMQP specific features. > I think we should think about a proper strategy for subclassing the > AMQDestination class to provide this extensible functionality.
Incase you hadn't noticed work towards this you will find a AMQHeadersExchange and an AMQUndefinedDestination. This should allow the Java client to be able to use any given Exchange + RoutingKey that may be presented via the replyTo. I believe to piece of code that we are missing out on is the creation of these Destinations something that we can very easily add via JNDI or as you say by creating a new sub class of AMQDestination. In fact the AMQUndefinedDestination is a new addition to M2.1 and by changing createDestination in AMQDestination to create an UndefinedDestination we can support any future destinations, of course with the caveat that any potential queue already exists on the broker. More work will be needed to instruct the client when the appropriate time is to create a temporary queue or request a durable queue. > We can then influence the AMQP WG to make this a standard by submitting > proposals to the JMS SIG. > > Regards, > > Rajith Attapattu > Red Hat > blog: http://rajith.2rlabs.com/ > -- Martin Ritchie
