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