I have logged this issue
http://java.net/jira/browse/JMS_SPEC-90
in order to capture the issue raised by Ruediger's thread "Why are Destinations resources and not Strings?"
This is really a placeholder currently - I haven't got any specific proposals to make (though I know Rüdiger had some
stronger ideas which he may wish to add to the JIRA). I just want this to be in JIRA so we can have a debate over which
issues we should work on next.
Nigel
Provide simpler mechanism to refer to queues and topics in a portable way
-------------------------------------------------------------------------
In the JMS 1.1 API, individual queues and topics are referred to not by name but by using javax.jms.Queue and
javax.jms.Topic objects, where the javax.jms.Queue and javax.jms.Topic interfaces both extend the javax.jms.Destination
interface.
This is because JMS 1.1 expects the way that a queue or topic is specified to be proprietary to a JMS provider. In order
to allow these proprietary aspects to be isolated from the application, JMS 1.1 expects javax.jms.Queue and
javax.jms.Topic objects to be "placed in a JNDI namespace by an administrator", for subsequent lookup by a portable
application.
Another benefit of storing queue and topic objects in JNDI is that it allows an administrator (or, in Java EE, a
deployer) to configure a mapping between the queue or topic JNDI name specified in the application with the actual queue
or topic name used by the JMS provider which can be modified without the need to change the application code.
Applications can by-pass this mechanism by using the createQueue(String name) and createTopic(String name) methods on
Session to convert a provider-specific queue or topic name to a javax.jms.Queue or javax.jms.Topic object. Since queue
or topic names are not portable this usage is, however, not recommended.
There are two main reasons why an application might want to avoid the need to bind and lookup objects in JNDI. For a
Java SE application which would otherwise have no use for JNDI, this is an additional complication for the application.
For a Java EE application which uses many thousands of destinations (e.g. a market data application that uses a separate
topic for every stock code on a stock exchange), then even though a JNDI provider comes built-in, having to create many
thousands of administered object is an administrative burden.
This issue therefore raises the issue of whether JMS should be enhanced to allow applications to refer to queues and
topics in a portable way without always having to create administered objects in JNDI. Possibilities include:
* Perhaps defining a portable format for queue and topic names to allow the use of createQueue(String name) and
createTopic(String name) methods on Session to be portable.
* Perhaps providing methods on JMSContext which allow a queue or topic to be specified as a string (and which therefore
call createQueue(String name) or createTopic(String name) internally) - though this might require the domain required
(queue or topic) to be passed in as an additional parameter.
* Perhaps adding some defaulting mechanism to the JNDI namespace to allow a javax.jms.Queue or javax.jms.Topic to be
looked up in JNDI in some special namespace and for the administered object to be created dynamically.
* There are other possibilities which might be considered as well.