Issue Details (XML | Word | Printable)

Key: JMS_SPEC-138
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Nigel Deakin
Votes: 0
Watchers: 0
Operations

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

Clarify whether you can call createContext on a QueueConnectionFactory or TopicConnectionfactory

Created: 01/Nov/13 12:01 PM   Updated: 01/Nov/13 12:22 PM
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Tags: jms21-forreview-minor
Participants: Nigel Deakin


 Description  « Hide

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.