On Tue, Oct 18, 2011 at 12:06 PM, Stuart Douglas <firstname.lastname@example.org> wrote:
If the 'other' instance is also a proxy, then both proxies will by definition be equal, as they will always resolve to the same underlying bean (as they are both being accessed by the same thread, that will have the same contexts active).
They are not comparing two normal objects they are comparing an object and an instance. We are defining how proxies equals work, which is to get the underlying real object and compare it to the incoming real object or the real object from the proxy.
Anything we specify here is going to break the transitive behaviour of equals, consider we have a proxy A and normal class instantiated with new B.
The normal class B has absolutely no knowledge of proxies, so will always compare the proxy instances fields directly, if we have the proxy forwarding the equals call to the underlying bean then you may end up with a situation where A.equals(B) is true, but B.equals(A) is false.
Good point. So to not break this contract, we would only say that proxies can compare against other proxies. If they want to compare a proxy to a normal object they would have to use the utility methods I described earlier to unpack it. We could add an equals static method to this utility as well.
HashCode has similar problems, if the proxy forwards it to the underlying bean, then the hash code will change as the underlying bean changes.But not within a Request scope or within a Session scope. I think this is ok actually. Much more so than the equals case. At least in the way people will actually use this in a web app. :)
I think we should specify that non-portable behaviour results, and tell people not to put proxies into a HashMap.
equals should only work with other client proxies, it should unpack and call equals on unpacked.
hashCode should just work, it should unpack and call hashCode on underlying object (contextual instance in spec speak right?)
On 19/10/2011, at 4:17 AM, Mark Struberg wrote:
> Hi folks!
> There is a problem still in the chain which is a bit more trickier. It's about equals() on contextual references.
> If the 'other' instance which gets compared with is a proxy as well, then we would first need to 'unpack' it and pass the underlying contextual instance into the comparison implementation. Otherwise accessing private fields from the 'other' will actually only hit the proxy, and not the 'real' target.
> But otherwise it should work fine.
> 1.) Should we specify this?
> 2.) What is the expected behaviour?
> 3.) Do we like to specify equals() for beans at all?
> 4.) Is there some established behaviour in other frameworks which heavily uses proxies?
> 5.) Should we at least specify that 'non portable behaviour results'?
> ----- Original Message -----
>> From: Pete Muir <email@example.com>
>> To: Mark Struberg <firstname.lastname@example.org>
>> Cc: email@example.com; Stuart Douglas <firstname.lastname@example.org>
>> Sent: Monday, March 14, 2011 12:52 PM
>> Subject: Re: [cdi-dev] calling 'equals' on a proxy?
>> Stuart, you had this one worked out right? I believe the spec says the behaviour
>> is unspecified.
>> On 7 Mar 2011, at 15:52, Mark Struberg wrote:
>>> Hi Pete, others!
>>> Do you remember our discussion about what should happen if equals() gets
>> called on a proxy?
>>> Should it route to the equals method of the currently proxied instance?
>>> cdi-dev mailing list
> cdi-dev mailing list
cdi-dev mailing list