On 12/01/2015 16:34, Matthew White wrote:
> Hello;
>
> Based on Java inheritance QCF and TCF objects have createContext methods. So is the general interpretation that (a)
> these should work and return a JMSContext and (b) should they work in a unified domain way.. i.e. should a JMSContext
> from a QCF be usable in a pubsub manner and vice-versa. This has been raised by a customer as it's not clear if they
> can.. in this case should they migrate their JNDI QCFs to CFs before using the JMS2.0 simplified API.
>
> It's a similar question in some ways as to the type of the object return from the createConnection method called on
> QCF/TCF objects.
Good questions. What do you think?
In JMS 1.1, the section "Method Inheritance across Messaging Domains" stated that you can't call queue-specific methods
such as createBrowser on a TopicSession or call topic-specific methods such as createDurableSubscriber on a
QueueSession, even though both methods are available through inheritance. These would throw an IllegalStateException.
I think this is a strong hint that you can't expect to be able to do queue-related things with the Topic-specific
interfaces, or topic-related things with the Queue-specific interfaces, even if method inheritance would appear to allow it.
So it would seem to me that you should not expect to be able to call createConnection (or createContext) on a
QueueConnectionFactory and use the resulting Connection to do topic-related things (and vice versa), though the spec
doesn't, as far as I can see, state this explicitly.
I think this is well worth clarifying and I will log this as an issue. We could either define that any operation on a
topic using a QueueConnectionfactory (and vice versa) must throw an exception, or simply state that whether it works is
not defined.
This issue has been with us (for createConnection) since JMS 1.1, so can clarifying this this wait for JMS 2.1,
especially if we are not sure what the clarification should state?
(I'd like to be able to wrap up the JMS 2.0 errata so we can get onto JMS 2.1)
Nigel