JBossDeveloper

could you post your patch

It is quite trivial, in HornetQSession.java, line 537:

I have built using a download github zip, so there is no version information. if you need that we can of course do that.

yeah thats the patch i used (well similar anyway) and get lots of errors in the integration tests, theres a few other places we use the address instead of the name, i will post a patch once i have run the test suite again

Andy, do you have any updates on this issue? Will it be fixed for 2.3?

Thanks!

ive spent 2 days working on it and its not as simple as first thought, the changes have quite an effect on the API and also on other protocols such as stomp, currently because we cant change the API or protocols we are unable to fix it.  i will leave the jira open but its unlikely to be fixed in 2.3.

Hmm, really bad news for us, but thanks a lot for the effort you spent on this. Would you be able to share some details of your findings. If you spent so much time on this I think it would be very beneficial for all of us to have some documented findings which could be taken up at any later stage, e.g. for a major release like HQ 3.0.0.

We are especially missing the bits which explain why this would affect the API and what API you are referring to. At least the HornetQ Core API and implementation looked to be quite clear and also consistent with the documentation. It was only the JMS implementation based on the Core API which did not seem to interact with the Core API in a consistent manner. While programming against the Core API we could not find any issues regarding the case where one address is assigned to multiple queues - neither on the sending nor the receiving end. Did you refer to required changes to the Core API? At least we cannot see any other API you could refer to as the JMS API is settled by the spec and the only thing in between is the HQ JMS implementation. If you were referring to the Core API how would those API changes look like? As I understand it they would affect anyone using the Core API as well as the HQ implementations on top. You also wrote required changes would impact other protocols like STOMP. How can this have impact on a text-oriented wire protocol? Or do you mean the way Stomp destinations are currently mapped to HQ addresses and queues? Based on my very highlevel understanding what is documented for Stomp matches perfectly to the Core API. While sending destinations are mapped to HQ addresses whereas while receiving Stomp destinations are mapped to HQ queues (I understand via their names).

Thanks for sharing more information!

so here is a list of findings i made and it isnt quite as clear as you think:

1. there are quite a few places where we use the address to either create a queue, create a consumer or query a a queue exists.

     changing this bit is quite easy, but there are more than one place where this change is made, not just the one you use, you can see some of them in a commit i made at https://github.com/andytaylor/hornetq/commit/5a642e817bc91379568f004b4a600d29ec468e9e

2. when jms resources are created we use this name and the same naming conventions to register mBeans with the available mBean server using our management API,  this would no doubt break any ones code who depends on this.

3. The JMSServer Manager API currently creates queues and topics only using a queue name but also uses the same naming convention, that is it will create an address jms.queue.name with the same queue name, this would need changing which requires a change to the API.

4. Stomp, yes you are correct that this maps to core, however, people typically use it with JMS and when we set the destination in the frame we use the same convention, so if the address and the queue name are different this will no doubt break peoples code again. (note it broke our tests and examples)

Im not saying that this is not something we can do its just that we have to factor in risk/timeframe etc, so doing it in 3.0.0 would make more sense.