The attached patch contains basic support for the common addressing syntax to be used by all clients.
The patch is incomplete as it is not functionally complete due to lack of a parser.
The patch also does not contain any tests as of yet. I want to investigate the possibility about reusing tests written for the python client and then supplement it with java based tests.
I'd appreciate your comments about the direction taken in this patch.
Suggestions and criticisms are most welcomed.
1. The required fields and methods to support the new addressing mechanism is added to AMQDestination itself. This was to ensure there is as little code changes as possible to the existing setup.
2. The code requires a parser for the new addressing syntax. Once that is available code will be added to use that to populate the required fields.
3. The new addressing support is only added to the 0-10 codepath as I am not sure there is sufficient protocol level support to implement it meaningfully in 0-8.
4. For now I am ignoring the browse option (I believe this value could be used for the noconsume field in BasicMessageConsumer)
5. For now I am ignoring reliability option as I am not quite sure how to tie that into the existing ack modes (perhaps I misunderstood).
6. I have not bothered to factor in any abstraction required to support AMQP 1.0, as I feel it's best served if we look at the client as a whole rather than piece by piece when figuring out the right level of abstraction.
7. I have removed the final keyword from _exchangeName, _exchangeClass, _isDurable, _isExclusive, _isAutoDelete to get more flexibility within the constructor methods. None of the above had any setter methods (well I added ones for exchangeName and exchangeClass for good reason) and are only set in the constructor or constructor like methods.
8. The equals method for AMQDestination needs to be modified to handle the new addressing syntax.
Ex. Consider a javax.jms.Destination dest1 with an address "foo" and another instance called dest2 with the same address. If the name resolves to an exchange, the queuenames contained within dest1 and dest2 would be different as a private temp queue is created for each if used by a consumer. If "foo" resolves to a queue then then the queuename would be the same for both instances. If an equals test is performed for dest1 and dest2 it should succeed for use cases, allthough the test criteria will be different.