pure SFSB are kind of @Dependent from a lifecycle point of view, right? So those would not get any CDI normalscoping client proxy anyway and hashCode and equals are directly treated by the EJB part of the stack. It should not make any difference whether you inject them via @EJB or @Inject. The same is true for @Stateless EJBs.
But what about SFSB which you put under the control of a CDI normal scope lifecycle? E.g. a @SessionScoped SFSB?
Imo those would get a CDI client proxy and thus the CDI rules apply if you @Inject a Contextual Reference for them into some place.
LieGrue,
strub
----- Original Message -----
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: Michael Remijan <mjremijan_at_yahoo.com>; "users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net>
> Sent: Friday, 13 September 2013, 18:58
> Subject: [ejb-spec users] Re: Question about spec 3.4.7 Session Object Identity
>
> SFSBs have an identity and EJB spec contains requirements for the
> equals() method invocation on the client proxies for all session beans -
> see 3.4.7 Session Object Identity.
>
> -marina
>
> On 9/12/13 9:50 PM, Mark Struberg wrote:
>> 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?
>>>
>>>
>