jms-spec
  1. jms-spec
  2. JMS_SPEC-140

Assumptions over Destination name within TCK

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None
    • 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.

        Activity

        Hide
        Nigel Deakin added a comment -

        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

        Show
        Nigel Deakin added a comment - 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
        Hide
        mbwhite added a comment -

        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.

        Show
        mbwhite added a comment - 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.
        Hide
        mbwhite added a comment -

        As commented by Nigel this should raised as TCK issue.

        Show
        mbwhite added a comment - As commented by Nigel this should raised as TCK issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            mbwhite
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: