Nigel, Ruediger,
I believe in all cases, this is currently on ConnectionFactories. Should
there be any distinction between:
.getTopic(String)
.createTopic(String)
e.g. getTopic would fail (throw Exception?) if the given topic does not
exist?
John
On Tue, Mar 27, 2012 at 10:30 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I have logged this issue
> http://java.net/jira/browse/**JMS_SPEC-90<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.
>
>
>