>
> 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.
The name createQueue is a dubious name. If we just wanted to lookup
the queue, it should been called lookupQueue and lookupTopic (never
create in the first place)
Because of the lack of a test, the dubious name,, you had dubious
interpretation of the rule, right? What resulted on .. say... 50% of
providers not creating the destination, and 50% doing it so.
If we just relax the spec, allowing the provider to decide wether or
not to create the destination, you will just have things as they are
today. i.e. It will be up to the provider to decide what's best for
his product.
But if you enforce the rule, you will have lots of users being forced
to a different semantics. I.e. you will be changing the API for these
users.
IMO we should just take this one easy and focus in other issues. The
provider may chose to throw an exception or to create the destination
(it should be up to the implementor).