I'd like to explain the ration behind this paragraph:
Our NormalScoping proxies are the called 'Client Proxies' and not to be confused with the proxies we generate for providing interceptors and decorators.
These proxies only get provided for NormalScoped beans like @SessionScoped, etc.
The point is that you cannot put such thing as key into lets say a Map anyway, because this would offend the Collections spec. Why? Simply because asking the map for this proxy would give you no result or some random one because the hash and equals would be different for each session. But the Collections contract requieres that the hash code and equals method remain stable for objects you put into them as key.
So while most containers in fact delegate those methods through to the contextual instance, you should not rely on it's value.
The same is essentially also true for e.g. @Stateless beans:
a.) they should not hold any state anyway as it's purely random which instance you get from the pool.
b.) if they hold state, then it's purely random to which of the pooled instances your EJB proxy points to for this very thread.
We had a long discussion about proxy behaviour about a year ago on this list. You might want to check the archives.
LieGrue,
strub
>________________________________
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>To: Michael Remijan <mjremijan_at_yahoo.com>
>Cc: "users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net>
>Sent: Thursday, 12 September 2013, 23:52
>Subject: [ejb-spec users] Re: Question about spec 3.4.7 Session Object Identity
>
>
>
>It's a bug in the CDI spec (and Weld because of that) that CDI rules are not adjusted for the EJB references.
>
>I filed https://issues.jboss.org/browse/CDI-400 to track this.
>
>thanks,
>-marina
>
>
>On 9/11/13 7:35 PM, Michael Remijan wrote:
>
>So I have a question about the spec section 3.4.7 Session Object Identity. If you run the examples in Glassfish 4 you get the expected results. So no problem there. What's interesting is if you replace @EJB with @Inject then the .equals() method no longer behaves as specified in 3.4.7. Now I know the spec is specifically for the @EJB annotation and @Inject is different but I still found this to be curious behavior. Was this expected? not expected?
>>
>
>
>