On Jan 18, 2008 11:31 AM, Martin Ritchie <[EMAIL PROTECTED]> wrote: > 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 did see these to classes when I looked at the code to provide fannout support. I think this is a step in the right direction. However I don't think we are quite there. I still think more work needs to be done. When I said we haven't utilized the full power, I based it on the following comments by Gordon which I will cut-paste here. "what exchanges to use, multiple bindings to a queue, whether and when things are declared & whether the 'passive' flag is used when so doing, whether the 'mandatory' flag is set on published messages, whether the exclusive flag is set when issuing a subscribe etc. etc." I believe a lot of these can be hidden behind the Destination abstraction. 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. > Yes that is the right approach. But as I said in the comment above, there's more we can do. > > 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. > When somebody sends me a replyTo, it's done witht the explicit understanding that the sender has already have this queue in place. That is the standard practise. > > > 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 > -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
