Clarify whether you can call createContext on a QueueConnectionFactory or TopicConnectionfactory

[glassfishrobot]

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.

Affected Versions

[2.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/138
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: The same issue applies to the classic API. If an application calls createConnection on a QueueConnectionFactory or TopicConnectionFactory, can the resulting Connection object be used with both queues and topics?

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: Taking both issues together, we have three possibilities if an application tries to perform an operation on a topic using a QueueConnectionFactory, or an operation on a queue using a TopicConnectionFactory:

1. An IllegalStateException must be thrown 2. The operation may work, or alternatively an IllegalStateException may be thrown. Applications which depended on this working would not be portable 3. The operation must work (as suggested above). This seems to be the best option, since defining that something "must work" is better than defining that something "must fail".

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-138