On 12/01/2015 19:29, Nigel Deakin wrote:
> 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
I was just about to log this as a new issue, then I spotted that I already logged (in Nov 2013)
https://java.net/jira/browse/JMS_SPEC-138
(Clarify whether you can call createContext on a QueueConnectionFactory or TopicConnectionfactory)
which was already in the list for JMS 2.1.
When I logged it I suggested a different approach to the one I mentioned above:
"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."
So we have three possibilities.
1. Any operation on a topic using a QueueConnectionFactory (and vice versa) must throw an exception
2. Any operation on a topic using a QueueConnectionFactory (and vice versa) may either throw an exception or it may work
(so code which depended on it working would not be portable)
3. Any operation on a topic using a QueueConnectionFactory (and vice versa) must work
We would need to decide whether this applied only to JMSContexts or to Connections and Sessions as well.
I rather like (3), since defining that something "must work" is better than defining that something "must fail". However
this may require changes to implementations (including the RI) this would be inappropriate for an errata and so would
need to wait for JMS 2.1.
I've updated the issue to mention {{createQueue}} as well as {{createContext}}, and to list the three options.
Nigel