[JMS_SPEC-140] Assumptions over Destination name within TCK Created: 05/Nov/13  Updated: 05/Nov/13  Resolved: 05/Nov/13

Status: Closed
Project: jms-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mbwhite Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

When running the tck



 Description   

The Session object for example has createQueue() and createTopic() methods - both taking a string 'name' that provider-specific. The Queue and Topic objects both have methods that can get this name.

The TCK includes a check that gets this and confirms that what is passed in on create is the same as what is got. Not unreasonable; however the TCK has made an assumption of the format of the string used to set. This might not be valid.



 Comments   
Comment by Nigel Deakin [ 05/Nov/13 ]

Sounds a fair comment, particularly if this is a new test in JMS 2.0.

Sorry to be bureaucratic, but if you think the TCK is incorrect can you please take this up directly with the organisation which supplied you with the TCK? You should have the necessary contact details at Java partner Engineering (part of Oracle). You don't need to log these in JIRA first. Email me directly if you need help finding the right contact. nigel.deakin@oracle.com

Comment by mbwhite [ 05/Nov/13 ]

Thanks for the comment - wanted to raise that to see if it sounded reasonable. In this case the TCK supplies something like "QueueNameOne" - and a provider may just say sorry that isn't valid for various reasons.. It could then have to treat it as 'shorthand' or abbreviation. Therefore the string returned could be different but in valid 'providerSyntax'...

No you're right to be bureaucratic - this should be a TCK issue.

Comment by mbwhite [ 05/Nov/13 ]

As commented by Nigel this should raised as TCK issue.

Generated at Sun Sep 25 04:04:58 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.