Hi Nigel,
You proposal makes sense to me. Any chance you could deal with similar
issue JMS_SPEC-90 <
http://java.net/jira/browse/JMS_SPEC-90> "Provide
simpler mechanism to refer to queues and topics in a portable way" at
the same time? Please see my update to that issue - all it requires is
stipulating similar rules for queue and topic names. We could even use
the same rules.
thanks,
Chris
On 12/6/2012 10:33 AM, Nigel Deakin wrote:
> On 14/11/2012 14:30, Nigel Deakin wrote:
>> Thanks for the comments. I think we should keep this list as small as
>> possible, but I am now proposing that we require
>> support for
>>
>> * Java letters
>> * Java digits
>> * Underscore (_)
>> * Full stop/period (.)
>> * Minus/hyphen (-)
>>
>> Note that this does not prevent JMS providers from supporting
>> additional characters. This would be just defining a set
>> that is guaranteed to be supported.
>>
>> Remember this is to allow a RA or an EJB container to generate
>> subscription names automatically. It would also be useful
>> if JMS specified that a JMS provider must support subscription names
>> up to a specified length. We could then specify
>> that any subscription name generated by a RA or EJB container must be
>> shorter than this.
>>
>> The choice of a length is somewhat arbitrary, but how about requiring
>> that a JMS provider must be able to handle
>> subscription names of up to 128 characters? (It needs to be long
>> enough to allow reasonably meaningful names to be
>> generated from application name, MDB name, cluster name etc combined
>> with some kind of hash to ensure that they are
>> unique).
>>
>> Again this would not prevent JMS providers from supporting names
>> longer than this. This is just defining a length which
>> is guaranteed to be supported.
>
> I haven't received any objections to this so I've now drafted the
> necessary changes.
>
> I think this is an important feature as it allows applications,
> resource adapters and application servers to generate subscription
> names with the certainty that they would be valid in any JMS provider.
>
> If you know of any JMS provider which does not already satisfy this
> proposed requirement (or which could not be enhanced to satisfy it)
> then please do let me know.
>
> In the spec, I've added a new section:
>
> ---------------------------------------------------------------------------------------------------------
>
> 6.11.5. "Subscription name characters and length"
>
> The JMS provider must allow a durable or non-durable subscription name
> to contain the following characters:
> • Java letters
> • Java digits
> • Underscore (_)
> • Dot (.)
> • Minus (-)
>
> JMS providers may support additional characters to these, but
> applications which use them may not be portable.
>
> The JMS provider must allow a durable or non-durable subscription name
> to have up to 128 characters.
> JMS providers may support names longer than this, but applications
> which use longer names may not be portable.
> ---------------------------------------------------------------------------------------------------------
>
>
> In addition I have added an entry to the change history in appendix 5,
> since this is an important requirement which I don't want people to miss.
>
> You can read both sections in the draft spec:
> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
>
>
> Nigel