Nigel,
Maybe it's helpful to bring the questions that arise into a logical order.
Q: Is this about static auto-creation?
A: No... as you have noted, that should be done by @JMSDestinationDefinitions (I had seen the discussions but not that it made it's way into the early draft).
Q: Is this about dynamic auto-creation?
A: Maybe, but that's a rather rare use-case, so in order to make the common case as easy as possible and the uncommon case possible, let's postpone that for a moment.
Q: If the destination already exists, does the client (sender or receiver) really care if it's a queue or a topic?
A: No... the code is generally exactly the same.
Q: What is the easiest possible way to express the logical destination name?
A: As a String.
Q: What's the easiest possible way to map such a hard coded String to a physical destination?
A: The admin of the JMS server can, when creating the physical destination, set the logical name (actually any number of aliases, if the topology allows).
Q: What are the disadvantages of this approach?
A: Tools can't easily find out, before the code runs, what logical destination names will be used, so using unmapped names would have to trigger an exception.
Q: How can this disadvantage be mended?
A: By using static auto-creation... all destinations you use in your code can be specified in a @JMSDestinationDefinition annotation in the same bean (and even overridden with a deployment descriptor, if need arises).
Q: Is there a way to specify the logical destination name in a @JMSDestinationDefinition?
A: Not yet, the name is currently specified to be the JNDI name, not the logical destination name... but that's solvable. Making destinations visible in JNDI could actually be optional.
If you think that any of these questions deserve different answers, I'm wrong. But I assume that this chain of thought is quite strong, given that we aim at the simplest possible solution for the clients.
Now let's return to dynamic auto-creation. I can see numerous alternatives:
a) Leave it undefined... the syntax of logical destination names is unspecified, just as sending to a non-existing destination is. So if you need dynamically created destinations, some JMS servers might interpret the logical destination name as some address (this is what currently is called a provider-specific destination name), but the code would not be portable.
b) Standardize on this behavior... the logical name would remain a logical name, and when senders and receivers agree on one such name, the routing has to work out (some questions remain open, though).
c) Add an extra call to the JMSContext to create physical destinations, taking the same parameters as the @JMSDestinationDefinition has attributes.
d) Create a destination object that holds the same properties as the @JMSDestinationDefinition has attributes, and pass that instead of the destination name string.
e) Encode the attributes that @JMSDestinationDefinition has into a standardized String... maybe something like "queue:myLogicalName?prop1=val1".
Do you see other alternatives? I prefer c) or e), but this may be a matter of taste.
Actually even more questions arise, where I don't have strong or complete answers to. I've already made some vague suggestions, but there may be other and better answers to them. I list them here for further discussion, but I think the basic questions above should be agreed on first.
Q: Is there an alternative to duplicating the logical destination name, once in the annotation, and once in the code?
Q: How do we guarantee that the destination specified in a @JMSDestinationDefinition is created in the same JMS server as the JMSContext connects to?
Rüdiger