On 24/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
I would not provide support for declaring destination as JNDI properties.
The question is.. Why not? We have to invent a way of allowing a pure JMS client access to richer AMQP functionality. At the moment I can declare, for example, a destination in my JNDI properties that maps onto a headers exchange. By sending to that destination I can do JMS over AMQP using functionality that is not available normally through the JMS API, but can be considered part of the 'configuration' of the destination specific to our implementation. I agee that JNDI properties is an inferior way of doing things, compared with having a richly typed interface. Its sole advantage is allowing a way around the limitations of the JMS API without extending it. This in turn means that applications can work to the pure JMS API, and take advantage of extra functionality as a configuration option. By all means, provide a better interface for doing this, but leave in quick and easy support for pure JMS users too. Rupert
