IMO option two is not correct. The address string contains destination
information, directives for creating/deleting or verifying and other
directives to control behaviour.
For example consider the following two addresses. They refer to the same Queue.
test-queue; {create:always}
test-queue;{assert:sender}
If you use option #2, then the destinations created using those
strings will fail the equality test.
That is why I think it's more correct to do the equality test on a
conceptual level instead of matching every aspect of the address
string itself.
As for the comments made by Alex, I don't think comparing the subject
is the right approach for every situation.
Comparing the subjects might make sense when sending to an exchange
(again only in certain situations), but not for queues. Also at the
time equals is called we may not know the 'type'. We could look at the
resolved property to determine this. Otherwise what are we going to do
?
What should we do for exchanges with more complicated routing
algorithms like Headers or XML exchange where the subject is not a
factor at all ? It gets complicated real soon when you look beyond the
simple cases.
If you look at it from a high level pov, we send messages to either a
Queue or an Exchange. They are the "destinations". So one could argue
that if you are sending to the same "exchange" then you are sending to
the same destination. I think that has a stronger argument that than
what you are suggesting.
How messages are matched onto queues is a function of the exchange.
And it's something that we should not try to factor into our equals
implementation.
Regards,
Rajith
On Fri, Mar 15, 2013 at 6:13 PM, Robbie Gemmell
<[email protected]> wrote:
> Personally I would probably go for option 2, though I see the existing
> comparison (presumably for the old BindingURLs) was already similarly
> lacking.
>
> At the very least I think the comment Alex made on the JIRA around the
> 'subject' from the Address string needs to be addressed. I seem to recall
> from reviewing a different change at some point, I noted that not
> specifying an exchange within an Address made it default to use of the
> amq.topic exchange somewhere under the covers. That suggests that after the
> change which has been made, for many users session.createTopic(<simple
> topic name>) could have unexpectedly started returning a lot of different
> Topic objects that always say they are equal when they are clearly not
> expected to be.
>
> Robbie
>
> On 11 March 2013 21:04, Rajith Attapattu <[email protected]> wrote:
>
>> Hi All,
>>
>> While fixing QPID-3769, I came across this issue.
>>
>> There are two options for implementing the equals method (and hashcode).
>>
>> 1. Check the "type" and "name" to ensure they both point to the same
>> "destination" (which could be a queue or an exchange in pre 1.0
>> terms).
>>
>> 2. Do a comprehensive check on the internal address data structure to
>> ensure that all fields, properties, options are the same.
>>
>> (Please note that comparing two address strings is not a good idea as
>> there can whitespaces).
>>
>> I prefer option one and have pasted the patch as a comment on the JIRA
>>
>> What do others think?
>>
>> Regards,
>>
>> Rajith
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
