Marina,
Responses below:
* Are interceptors supported on EJB 2.x beans?
- No, but is there a reason o disallow @PostConstruct/_at_PreDestroy on
interceptors of EJB 3 beans that implement SessionBean? I am fine either
way -- it's an edge case...
* We'll need to discuss the above 2 separately.
- OK.
* This will be a new feature. Currently it's not portable.
- OK. Do I need to enter a JIRA?
* Will replacing "common state" with "instance variables" make it clearer?
- My opinion is that this is clear enough already...
Cheers,
Reza
On 7/29/2011 7:40 PM, 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3797 - Release Date: 07/29/11
>
>