My email client cut off text in all emails that I sent on Fri around
4pm. I'll try to reconstruct my full email as I was going through Reza's
comments in a separate reply.
-marina
Marina Vatkina wrote:
> Sorry guys, had several firedrills in my other tasks :(.
>
> Reza,
>
> Reza Rahman wrote:
>> Marina,
>>
>> My input:
>>
>> # XXX marked items:
>> * getContextData is pretty clear to me -- anything that was put in by
>> an interceptor pretty much (page 68 and 126).
> done
>> * If I understand it correctly, I don't think the SessionBean
>> interface bean meta-data restrictions apply to Interceptor life-cycle
>> call-backs (page 70).
>
> Are interceptors supported on EJB 2.x beans?
>
>> * I don't see a good reason session synchronization methods should be
>> limited to one (page 70).
>> * I think if there are multiple @Remove methods, their
>> retainIfException values can be different. I don't think this needs
>> further clarification (page 73).
>
> We'll need to discuss the above 2 separately.
>> * I think local and no-interface beans should be accessible
>> cross-application vis their global JNDI name (pages 77 and 398).
>
> This will be a new feature. Currently it's not portable.
>> * I think we should support PostConstruct method callbacks as
>> business methods (page 86).
>
> I removed the XXX
>> * wasCancelCalled should not be invoked if there is no asynch method
>> (pages 87 and 94).
>
> done
>> * To me “common bean state” in the context of stateless session beans
>> means any instance variable value that can be used across method
>> invocations. I don't think this needs further clarification (page 89).
>
> Will replacing "common state" with "instance variables" make it clearer?
>> * We can pick either EJBException or NoSuchEJBException for bad
>> singletons. I guess NoSuchEJBException would be more consistent with
>> stateless and stateful (page 98).
>
> It actually says javax.ejb.NoSuchEJBException