EJB 3.1 4.10.4 No-Interface View Reference Class
"The container provider is responsible for providing the implementation
of the equals and hashCode
methods for no-interface view reference, in conformance with the
requirements of section [3.6.5]."
It is covered in the TCK ejb30/lite/view/equals. (With the exception of
hashCode AFAIK.)
Making toString() a business method has the disadvantage that any
printing (/ logging) of a reference needs to activate an instance. This
can lead to interesting loops if business invocations are failing for
some reason.
+1 on excluding Object.class methods.
Carlo
On 02/15/2012 12:19 AM, David Blevins wrote:
> On Feb 14, 2012, at 2:41 PM, Marina Vatkina wrote:
>
>> Experts,
>>
>> The current EJB spec (see section 4.9.8) defines a no-interface view business methods as
>>
>> "All public methods of the bean class and any superclasses are exposed as business methods through the no-interface view."
>>
>> This would include all public methods of the Object.class
>>
>> Do we want to restrict this list to toString() method only?
> It might already be required elsewhere, at least in part.
>
> I know there are tests for equals() wrt to business local views. Haven't checked if the same tests exist for no-interface views. If they don't, they should.
>
> Someone asked me a month or two ago about finalizer methods on no-interface views as well. Those shouldn't be business methods either.
>
> We currently treat all Object.class methods as non-business methods. I'd have to double check our impl to see what happens if you override toString(), but I know for sure if you don't we will give you a default toString() that includes some internal ejb metadata.
>
> Definitely +1 to explicitly excluding Object.class methods. Open to including toString() as a business method in either overridden or non-overriden form if people want that.
>
>
> -David
>