(Changing thread title to match the JIRA issue you raised)
Clebert,
On 15/07/2011 21:30, Clebert Suconic wrote:
> 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).
Thanks for confirming that. I mentioned my own product only to illustrate that there doesn't seem to be a CTS test which
tests the circumstances when createQueue/createTopic throws a JMSException.
I agree that the JMS spec strongly hints that these methods shouldn't create the physical queue or topic, but are purely
convenience methods to convert a provider-specific name to a javax.jms.Queue or javax.jms.Topic object.
The products I have come across which create destinations automatically (Clebert mentioned ActiveMQ, which I think does
this by default) don't, I think, do it when createQueue/createTopic is called, but when the Queue or Topic object is
used. So in the narrow sense it might be argued that such products aren't breaking the instruction that "this method is
not for creating the physical queue.". However the spec does seem to expect there to be an explicit administrative
operation to create a queue or topic, which is clearly not being performed in such cases.
However JMS 1.1 has been use for a very long time and vendors have taken differing design choices, aided by the absence
of any CTS tests that enforce a particular interpretation. Now, that doesn't mean we can never "tighten up" the spec and
CTS tests in a way which requires existing vendors to change, but we need to consider each such case carefully.
In this case (and I should declare an interest) my view is that allowing destinations to be created "on demand" rather
than requiring them to be created administratively in advance, is not in itself a bad thing. It seems to be a useful
feature consistent with our shared goal of ease of use. So even if it was not explicitly catered for in the JMS 1.1 spec
we shouldn't be rushing to forbid it.
So I think the best way to approach this would be to consider how to expand the scope of JMS to cater for both modes of
operation. Here is my suggestion:
1. Clebert's JIRA issue (JMS_SPEC-31) asks that "session.createQueue and createTopic create server side destinations
case they don't exist". I propose we don't adopt this, since this would be a change to an existing API method for
*everyone*, both those that currently require destinations to be created administratively and those which create them
on-demand.
2. We reiterate, if needed, the existing javadoc which states that createQueue/createTopic don't physically create the
destination.
3. We leave unchanged the existing javadoc which doesn't mandate the circumstances where createQueue/createTopic should
throw an exception.
4. We modify the JMS spec (in the various places needed) to cater for the possibility that the operation of
administratively creating a destination is a no-op, with the destination created lazily.
5. If EG members think it is needed (and I'm not sure, so please tell me), we could consider adding more API - such as
to allow a application to determine whether (1) a given destination name or (2) a given javax.jms.Destination can be
used by a given session to send/receive messages.
Comments?
Nigel