jms-spec
  1. jms-spec
  2. JMS_SPEC-138

Clarify whether you can call createContext on a QueueConnectionFactory or TopicConnectionfactory

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      In the JMS 2.0 API, the legacy JMS 2.0 interfaces QueueConnectionFactory and TopicConnectionfactory inherit the methods createContext from ConnectionFactory.

      However, this implies that an object which is specific to either queues or topics is capable of generating an object (a JMSContext) that must work with both queues and topics.

      Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the createTopic method which a QueueSession inherits from Session. It lists a number of inherited methods which must throw an IllegalStateException.

      The absence of createContext from that list means that the JMS 2.0 specification currently requires that calling createContext on a QueueConnectionFactory or TopicConnectionfactory must be supported.

      We might wish to consider whether we should extend the list in 9.2 to require that calling createContext on a QueueConnectionFactory or TopicConnectionfactory must similarly throw an IllegalStateException. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

      Perhaps the best approach is to confirm that these methods must be supported, and that the JMSContext that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.

        Activity

        Nigel Deakin created issue -
        Nigel Deakin made changes -
        Field Original Value New Value
        Description In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}} that works with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        Should we extend this list to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}.

        Since JMS 2.0 is already released it may be too late to require this, but I think we should at least make it clear that there is no requirement for providers to implement these methods, and that they may throw an {{IllegalStateException}}.

        We could also add that if a provider does implement these methods then the {{JMSContext}} that is returned must support both queue and topics. Providers must never return a {{JMSContext}} that is specific to a particular domain.


         
        In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        Should we extend this list to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}.

        Since JMS 2.0 is already released it may be too late to require this, but I think we should at least make it clear that there is no requirement for providers to implement these methods, and that they may throw an {{IllegalStateException}}.

        We could also add that if a provider does implement these methods then the {{JMSContext}} that is returned must support both queue and topics. Providers must never return a {{JMSContext}} that is specific to a particular domain.


         
        Nigel Deakin made changes -
        Description In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        Should we extend this list to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}.

        Since JMS 2.0 is already released it may be too late to require this, but I think we should at least make it clear that there is no requirement for providers to implement these methods, and that they may throw an {{IllegalStateException}}.

        We could also add that if a provider does implement these methods then the {{JMSContext}} that is returned must support both queue and topics. Providers must never return a {{JMSContext}} that is specific to a particular domain.


         
        In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        Should we extend this list to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}?

        Since JMS 2.0 is already released it may be too late to require this, but I think we should at least make it clear that there is no requirement for providers to implement these methods, and that they may throw an {{IllegalStateException}}.

        We could also add that if a provider does implement these methods then the {{JMSContext}} that is returned must support both queue and topics. Providers must never return a {{JMSContext}} that is specific to a particular domain.


         
        Nigel Deakin made changes -
        Description In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        Should we extend this list to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}?

        Since JMS 2.0 is already released it may be too late to require this, but I think we should at least make it clear that there is no requirement for providers to implement these methods, and that they may throw an {{IllegalStateException}}.

        We could also add that if a provider does implement these methods then the {{JMSContext}} that is returned must support both queue and topics. Providers must never return a {{JMSContext}} that is specific to a particular domain.


         
        In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        The absence of {{createContext}} from that list means that the JMS 2.0 specification currently requires that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must be supported.

        However we might wish to consider whether we should extend the list in 9.2 to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

        Perhaps the best approach is to confirm that these methods must be supported, and that the {{JMSContext}} that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.


         
        Nigel Deakin made changes -
        Description In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        The absence of {{createContext}} from that list means that the JMS 2.0 specification currently requires that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must be supported.

        However we might wish to consider whether we should extend the list in 9.2 to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

        Perhaps the best approach is to confirm that these methods must be supported, and that the {{JMSContext}} that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.


         
        In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        The absence of {{createContext}} from that list means that the JMS 2.0 specification currently requires that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must be supported.

        We might wish to consider whether we should extend the list in 9.2 to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

        Perhaps the best approach is to confirm that these methods must be supported, and that the {{JMSContext}} that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.


         
        Nigel Deakin made changes -
        Description In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        The absence of {{createContext}} from that list means that the JMS 2.0 specification currently requires that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must be supported.

        We might wish to consider whether we should extend the list in 9.2 to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} should similarly throw an {{IllegalStateException}}. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

        Perhaps the best approach is to confirm that these methods must be supported, and that the {{JMSContext}} that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.


         
        In the JMS 2.0 API, the legacy JMS 2.0 interfaces {{QueueConnectionFactory}} and {{TopicConnectionfactory}} inherit the methods {{createContext}} from {{ConnectionFactory}}.

        However, this implies that an object which is specific to either queues or topics is capable of generating an object (a {{JMSContext}}) that must work with both queues and topics.

        Section 9.2 of the JMS 2.0 specification "Method inheritance across messaging domains" addresses the general issue of domain-specific interfaces inheriting methods which are not appropriate to that particular messaging domain, such as the {{createTopic}} method which a {{QueueSession}} inherits from {{Session}}. It lists a number of inherited methods which must throw an {{IllegalStateException}}.

        The absence of {{createContext}} from that list means that the JMS 2.0 specification currently requires that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must be supported.

        We might wish to consider whether we should extend the list in 9.2 to require that calling {{createContext}} on a {{QueueConnectionFactory}} or {{TopicConnectionfactory}} must similarly throw an {{IllegalStateException}}. This would be more consistent, though since JMS 2.0 is already released it may be too late to require this since it would probably constitute an incompatible change.

        Perhaps the best approach is to confirm that these methods must be supported, and that the {{JMSContext}} that is returned must support both queue and topics. This would not remove any functionality from users and so not be an incompatible change. And it is unlikely that providers would have any difficulties implementing it.


         
        Nigel Deakin made changes -
        Tags jms21-forreview-minor jms21-forreview-minor jms20-errata

          People

          • Assignee:
            Unassigned
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: