Hello;
(1) The simplified API is inherently cross-domain - so happy with the
option of the createContext working on QCF/TCF and then being able to use
it cross domain.
(2) Using a domain specific operation such as createQueue on a
TopicSession - currently is a IllegalStateException; this make sense to
me.. as you are explicitly mixing domains
(3) What is less obvious is what should createConnection() on a QCF
return? Should it be a Connection - therefore cross domain, or a
QueueConnection and therefore fixed to point-point.
I think (2) and (3) are subtlety different issues.
Agree that this is too much for the errata!
Regards,
Matthew B. White
Architect: IBM MQ JMS, Connectivity & Integration
Phone: 44-1962-817653
E-mail: WHITEMAT_at_uk.ibm.com
About.me: about.me/matthewbwhite
Find me on: and within IBM on:
Hursley Park
Hursley , SO212JN
United Kingdom
"The wrong answers are the ones you go looking for when the right answers
stare you in the face."
From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr368-experts_at_jms-spec.java.net
Date: 13/01/2015 17:21
Subject: [jms-spec users] [jsr368-experts] Re: createContext on
Queue and Topic Connection Factories
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU