Cancel my feedback on this issue - replied to soon. May weigh in again later.
----- Original Message -----
From: tom.barnes_at_oracle.com
To: jsr343-experts_at_jms-spec.java.net
Sent: Sunday, July 17, 2011 4:10:24 PM GMT -05:00 US/Canada Eastern
Subject: [jsr343-experts] Re: Session.createQueue / createTopoic
I think words like "may" and "should" in a
specification can reduce application portability
as they introduce the possibility of different
providers having significantly different behaviors for rehosted apps.
If there's a need for dynamic destination creation APIs, I'd advocate
adding new methods specifically for the purpose.
Tom
----- Original Message -----
From: clebert.suconic_at_gmail.com
To: jsr343-experts_at_jms-spec.java.net
Sent: Friday, July 15, 2011 4:30:58 PM GMT -05:00 US/Canada Eastern
Subject: [jsr343-experts] Re: Session.createQueue / createTopoic
sorry, my last email was sent by mistake... was still typing and the
send was pressed by accident...
What I meant to say is.. the API states this.
"Note that this method is not for creating the physical queue. The
physical creation of queues is an administrative task and is not to be
initiated by the JMS API. The one exception is the creation of
temporary queues, which is accomplished with the createTemporaryQueue
method."
I think we should remove that text, or to make clear a provider may
decide to create the Queue, as this is everybody's implementation.
We haven't allowed createQueue in our product to automatically create
the queue as we interpreted the rule as written.
As for the test, I guess I confused it with IllegalStateTests which
tests createQueue, but for a different purpose (createQueue shouldn't
be allowed on a TopicSession).