[cdi-dev] Clarification: CDI and its relationship with Session beans
abhirockzz at gmail.com
Fri Feb 13 07:31:36 EST 2015
Thanks Arjan. This definitely helped.
My basic point was that the statement in *Section 1.2.2* implies that the *CDI
container destroys the Session bean instance* - which is definitely not the
case (you seem to share the same opinion), because the CDI container is
dealing with a proxy anyway.
*Section 7.3.3* conveys this more accurately IMO. That's I wanted to point
this out and check what the experts feel about (maybe slightly) re-wording
Section 1.2.2 to avoid any ambiguity or confusion :-)
On Fri, Feb 13, 2015 at 3:37 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> On Friday, February 13, 2015, Abhishek Gupta <abhirockzz at gmail.com> wrote:
>> Hello folks - just wanted to gain some clarity here
>> *Section 1.2.2* of the spec doc states that
>> [quote] *Any session bean instance obtained via the dependency injection
>> service is a contextual instance. It is bound to a lifecycle context and is
>> available to other objects that execute in that context. The container
>> automatically creates the instance when it is needed by a client. When the
>> context ends,the container automatically destroys the instance* [/quote]
>> (being a relative beginner) My first impression after reading this
>> statement was the following - "*If I use @Inject for DI of an EJB into
>> my class, the CDI container takes over it's control and actually destroys
>> the instance after the context ends*".
>> If we think in terms of @Stateless EJBs, this *might *not be the case
> Indeed, and I would even say IS not the case. Even if the container would
> not pool instances (like JBoss effectively does since Wildfly 8), then
> every call to the injected bean can still go to another instance of the
> injected bean.
> There's therefor IMHO no concept of a bean to destroy, since there was
> never any particular instance associated with the context in which the bean
> was injected.
> The way I see it, a stateless bean from the point of view of a client is
> close to an MDB or Servlet. You "send" a call to it, but there are no
> guarantees which actual instance is going to service it.
> Hope this is correct and hope it helps,
> Kind regards,
> Arjan Tijms
>> since the EJB container might choose to return the instance to back to
>> the EJB pool (I understand that this is not mandated by the EJB spec).
>> Keeping this in mind, do you think that the statement in section 1.2.2 is
>> correctly framed since it seems as if the CDI container will actually
>> destroy the EJB instance?
>> I think this is better specified in *Section 7.3.3* (this section dives
>> in deeper)
>> [quote] *When the destroy() method is called, the container simply
>> discards this internal reference*.[/quote]
>> This might be a minor thing - but I am just trying to provide a
>> 'beginner' point of view of and how he/she might interpret the contents of
>> the specification with regards to its relationship with EJBs
>> Feel free to correct me in case I am missing something.
>> Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev