On 3/28/13 2:35 AM, Mark Struberg wrote:
> It was not thaaat long ;)
>
> What we still need to do is to go through the list of Object.class methods and identify which of them shall get proxied and also the ones must _not_ get proxied.
>
>
> As example:
>
> * toString() should get proxied imo. Otherwise logging and lots of business stuff will not work
I'm not sure though... Object.toString is only useful for logging the
instance hashcode. An overwritten method would be proxied because it's
defined on another class.
>
> * What about hashCode() and equals()? We should keep in mind that it's just not possible to store a (non @Dependent) managed bean into a Map or Set anyway as this would infringe the Collection contract. Should we delegate them to the internal instance nonetheless and just point out the implications to Collections?
Only for the no-interface view: equals() on the proxy has a special
meaning in the EJB spec:
"The equals method always returns true when used to compare references
to the same business interface type of the same stateless session bean.
The equals method always returns true when used to compare references to
the no-interface view of the same stateless session bean. Stateless
session bean references to either different business interface types or
between an interface type and a no-interface view or to different
session beans will not be equal."
>
> * clone(): hard to get this right...
>
> * wait(..), notifyAll(), getClass(): of course not. They are final anyway thus we cannot proxy them.
>
>
>
> I could think about explicitly declaring Object#toString() to be a business method. They sometimes get decorated or get used to do some lazy init which might need the EJB security in pace. This should btw go hand in hand with the CDI spec.
>
> Oh another thing which popped up yesterday: in EJB only public methods are business methods. But in CDI all non-private methods are business methods. Thus what about a @Stateful @SessionScoped UserInfo?
That's a bigger change ;)
Let's start with filing issues in both areas.
thanks,
-marina
>
>
> LieGrue,
> strub
>
>> ________________________________
>> From: Jean-Louis MONTEIRO <jeanouii_at_gmail.com>
>> To: jsr345-experts <jsr345-experts_at_ejb-spec.java.net>
>> Sent: Thursday, March 28, 2013 9:08 AM
>> Subject: [ejb-spec users] [jsr345-experts] Fwd: Re: Final methods in a bean class?
>>
>>
>> Marina,
>>
>>
>>
>> Hope the offline match hasn't been that long nor boring :D
>>
>>
>> Ok for me, it just makes things clearer and relevant because as per Mark's remarks and proxying mechanisms.
>>
>>
>> JLouis
>>
>>
>>
>> 2013/3/28 Marina Vatkina <marina.vatkina_at_oracle.com>
>>
>> After a longer discussion with Mark offline and not to allow users to shoot themselves into a foot, the new proposal is to change both statements as follow:
>>> (a) "All non-static public methods of the bean class and of any superclasses except the java.lang.Object, are exposed as business methods."
>>>
>>> (b) "Business methods exposed through the no-interface view must not be declared final."
>>>
>>> Let me know if anybody disagrees.
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>> On 3/27/13 11:36 AM, Marina Vatkina wrote:
>>>
>>> Experts,
>>>> The EJB spec currently requires that if a bean exposes a no-interface view (see 4.9.8 Session Bean’s No-Interface View):
>>>>
>>>> (a) "All public methods of the bean class and of any superclasses except the java.lang.Object, are exposed as business methods through the no-interface view."
>>>> (b) "All methods of the bean class and any superclasses must not be declared final."
>>>>
>>>> For all other views the rules for a *business method* is
>>>> "The method must not be declared as final or static."
>>>>
>>>> Does any of you see a problem with removing the rule (b) and changing the rule (a) to:
>>>>
>>>> "All non-final non-static public methods of the bean class and of any superclasses except the java.lang.Object, are exposed as business methods through the no-interface view."
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>>
>>
>>
>> --
>> Jean-Louis
>>
>>
>>
>> --
>> Jean-Louis
>>
>>