Issue Details (XML | Word | Printable)

Key: JMS_SPEC-94
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Nigel Deakin
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
jms-spec

Define what characters are valid in a durable (or shared subscription) name

Created: 17/Apr/12 04:31 PM   Updated: 20/Mar/13 03:44 PM   Resolved: 20/Mar/13 03:44 PM
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 2.0PD, 2.0

Time Tracking:
Not Specified

Tags: pd20-added
Participants: chris.barrow and Nigel Deakin


 Description  « Hide

The JMS 1.1 specification does not specify what characters are valid in a durable subscription name.

It is proposed that the JMS 2.0 specification defines a minimum set of characters which are valid in a durable or non-durable subscription name.

This is needed to allow portable applications to be created. It is also needed because EJB_SPEC-41 states that if a MDB is defined with subscriptionDurability set to Durable but subscriptionName is not set then the container will automatically set subscriptionName to a suitably unique global name of the MDB, and the container vendor needs to be sure that the name it generates will always be a legal subscription name.



Nigel Deakin added a comment - 31/May/12 10:27 AM

In addition, the JMS 2.0 should specify the minimum length of durable subscription name that a JMS provider should support.


chris.barrow added a comment - 06/Dec/12 08:00 PM - edited

Issue JMS_SPEC-90 "Provide simpler mechanism to refer to queues and topics in a portable way" is related. Could we deal with that issue at the same time? It could easily be resolved by stipulating the same rules for queue and topic names as those proposed for durable subscription name (minimum set of characters and length that must be supported), as noted in a comment I added to that issue.


Nigel Deakin added a comment - 20/Mar/13 03:44 PM

This issue is resolved in the JMS 2.0 final release. Marking issue as resolved with a "fix version" of 2.0