I would argue (and probably lose) that something that worked in 99% of cases as expected would be better than something that never does.<div><div><br></div><div>I will reread Stuarts arguments, but it seems to me that we can specify how equals works with client proxies.<br>
<br><div class="gmail_quote">On Tue, Oct 18, 2011 at 1:56 PM, Pete Muir <span dir="ltr">&lt;<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 18 Oct 2011, at 21:42, Rick Hightower wrote:<br>
<br>
&gt; Currently the docs say this.... 5.4.2.<br>
&gt;<br>
&gt; •Behavior of all methods declared by java.lang.Object, except for toString(), is undefined for a client proxy<br>
&gt; •Portable applications should not invoke any method declared by java.lang.Object, except for toString(), on a client proxy<br>
&gt;<br>
&gt; I so don&#39;t agree with what is in the spec. now on this subject.<br>
&gt; (Realizing that it is a work in progress...)<br>
<br>
</div>Not really, this is unchanged since 1.0. We don&#39;t currently have plans to change this.<br>
<div class="im"><br>
&gt;<br>
&gt; I think we should change this and call the underlying implementation for these methods.<br>
&gt; Also equals and hashCode should work by unpacking and comparing the contextual instance.<br>
<br>
</div>Please take a look at Stuart&#39;s follow up to Mark&#39;s email, he has investigated the options thoroughly, and found there is no solution that can correctly obey the rules for equals. For this reason it&#39;s better to keep it unspecified, as it warns people not to rely on this behavior.<br>

<div class="im"><br>
&gt;<br>
&gt; Off topic....<br>
&gt;<br>
&gt; It would be nice if there was a utility API that implementations had to implement that had these methods<br>
&gt;<br>
&gt;<br>
&gt; isProxy (lets you know if an object is a client proxy)<br>
&gt; getUnproxiedVersion (gives you the underlying unproxied version of the object)<br>
&gt;<br>
&gt;<br>
&gt; (It may exist already.)<br>
<br>
</div>I don&#39;t believe there is, so file a CDI issue and we can discuss / add it. It should be relatively trivial (require any client proxy to implement an interface e.g. ClientProxy and provide a method on getUnderlying() or similar).<br>

<div class="im"><br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 18, 2011 at 10:17 AM, Mark Struberg &lt;<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>&gt; wrote:<br>
&gt; Hi folks!<br>
&gt;<br>
&gt; There is a problem still in the chain which is a bit more trickier. It&#39;s about equals() on contextual references.<br>
&gt;<br>
&gt; If the &#39;other&#39; instance which gets compared with is a proxy as well, then we would first need to &#39;unpack&#39; it and pass the underlying contextual instance into the comparison implementation. Otherwise accessing private fields from the &#39;other&#39; will actually only hit the proxy, and not the &#39;real&#39; target.<br>

&gt;<br>
&gt; But otherwise it should work fine.<br>
&gt;<br>
&gt;<br>
&gt; Wdyt?<br>
&gt;<br>
&gt; 1.) Should we specify this?<br>
<br>
</div>See Stuart&#39;s response, I would be very leery of requiring behavior which broke the fundamental contract of equals(). If we can&#39;t fully support the correct behavior, it&#39;s better to leave it unportable.<br>

<div class="im"><br>
&gt;<br>
&gt; 2.) What is the expected behaviour?<br>
&gt;<br>
&gt; 3.) Do we like to specify equals() for beans at all?<br>
&gt; 4.) Is there some established behaviour in other frameworks which heavily uses proxies?<br>
<br>
</div>Not AFAIK. We played around for ages with this in Seam and Weld, and have something that gives you 99% correct behavior, but there are still edge cases.<br>
<div class="im"><br>
&gt; 5.) Should we at least specify that &#39;non portable behaviour results&#39;?<br>
<br>
</div>We do, see Rick&#39;s reference above.<br>
<div><div></div><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt; LieGrue,<br>
&gt; strub<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: Pete Muir &lt;<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>&gt;<br>
&gt; &gt; To: Mark Struberg &lt;<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>&gt;<br>
&gt; &gt; Cc: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>; Stuart Douglas &lt;<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>&gt;<br>
&gt; &gt; Sent: Monday, March 14, 2011 12:52 PM<br>
&gt; &gt; Subject: Re: [cdi-dev] calling &#39;equals&#39; on a proxy?<br>
&gt; &gt;<br>
&gt; &gt; Stuart, you had this one worked out right? I believe the spec says the behaviour<br>
&gt; &gt; is unspecified.<br>
&gt; &gt;<br>
&gt; &gt; On 7 Mar 2011, at 15:52, Mark Struberg wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt;  Hi Pete, others!<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Do you remember our discussion about what should happen if equals() gets<br>
&gt; &gt; called on a proxy?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Should it route to the equals method of the currently proxied instance?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  LieGrue,<br>
&gt; &gt;&gt;  strub<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  _______________________________________________<br>
&gt; &gt;&gt;  cdi-dev mailing list<br>
&gt; &gt;&gt;  <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt; &gt;&gt;  <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cdi-dev mailing list<br>
&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Rick Hightower<br>
&gt; <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037</a><br>
&gt; Profile<br>
&gt;<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><b>Rick Hightower</b><br>(415) 968-9037 <br><a href="http://www.google.com/profiles/RichardHightower" target="_blank">Profile</a> <br><br>
</div></div>