Rüdiger,
Perhaps it's time for us to have a phone call about this - I'll send you an email.
Nigel
On 26/04/2012 10:22, Rüdiger zu Dohna wrote:
> 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
>