Thanks for sharing your thoughts on this.
I currently have a patch in our internal branch that does validate the queue when trying to create the QueueBrowser.
So certainly in line with what you mentioned about checking for the presence of the queue.
(I also agree with you that creating queues when creating consumers by default is an aberration)
However the TCK failures are certainly forcing us to look at Queue validation more broadly. Hence my questions.
It seems to me we need several types of validation.
1. One that checks for the presence of a queue, which as you mention needs to be performed every time we use the Queue to create something (ex consumers, browsers..etc)
2. One that tries to resolve an address to see if it's indeed a Queue or a Topic (unless explicitly specified). This is a tricky one and the root cause of the TCK failures.
3. One that actually acts upon the address instructions to create, assert a Queue and acts on the node and link properties as instructed.
When I mentioned about validation with jndi or when getQueueName() was invoked, I was thinking more about #2 and,
When I mentioned "If that's the case then I believe we don't need the validationQueue method here", I actually meant that step #2 should probably have been done before, not inside the QueueBrowser implementation. But in making that point I totally missed the fact that the JMS API expects us to check the presence of the queue as well. So I agree step #1 is indeed needed anytime you create something with a Queue.
Currently we do all 3 in one method which is not sufficient to satisfy the above cases.
Rob, here's another interesting question.
Do we need to do step #3 when we create the QueueBrowser or when we create the actual consumer(s) when getEnumeraiton() is called ?
That is if we need to create/assert the node, node bindings and link properties/bindings at the time we create the Browser or when we create the actual consumers.