Issue Details (XML | Word | Printable)

Key: JMS_SPEC-140
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: mbwhite
Votes: 0
Watchers: 0
Operations

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

Assumptions over Destination name within TCK

Created: 05/Nov/13 11:12 AM   Updated: 05/Nov/13 12:01 PM   Resolved: 05/Nov/13 12:01 PM
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Environment:

When running the tck


Tags:
Participants: mbwhite and Nigel Deakin


 Description  « Hide

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.



Nigel Deakin added a comment - 05/Nov/13 11:53 AM

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


mbwhite added a comment - 05/Nov/13 12:01 PM

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.


mbwhite added a comment - 05/Nov/13 12:01 PM

As commented by Nigel this should raised as TCK issue.