Provide simpler mechanism to refer to queues and topics in a portable way

[glassfishrobot]

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.

Affected Versions

[1.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/90
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: I would vote for the first option (defining a portable format for queue and topic names to allow the use of createQueue and createTopic). The portable format just needs to specifiy a minimum set of characters which are valid in a topic or queue name. This is very similar to JMS_SPEC_94 (for durable or shared subscription name).

I think this would be a very useful enhancement and we should try to get it into JMS 2.0.

[glassfishrobot]

@glassfishrobot Commented axel_podehl said: I think createTopic/createQueue is already used in many applications and the real behaviour differs from provider to provider.

How about adding a method like this one, similar to the properties of the JMSDestinationDefinition annotation:

Session.createTopic( String jndiName, String destinationName, String description, String[] properties)

or along the lines of ConnectionMetaData:

Session.createTopic( String jndiName, DestinationMetaData destDefinition )

and Session.createTopic( String name ) would then use the method above, and each provider should comment on the actual arguments used.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-90