You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Gurkan Erdogdu <gu...@yahoo.com> on 2010/08/19 09:05:18 UTC
EJB Bean Stateful Bean Remove Methods
Hi;
I am trying to understand the current implementation in our EjbBeanProxyHandler
and BaseEJBBeans.
If I understand correctly,
1*) BaseEjbBeans hold map : proxy --> dependent EJB stateful instance
2*) When a call is made to remove method of the stateful instance and bean is
dependent scope, then remove "dependent EJB stateful instance" from BaseEJBBean
"map" and do nothing
3*) When the bean is destroyed and if it is dependent, then call Remove method
of the stateful instance over container. But if the stateful is removed from map
via item-2, then no remove method invocation occurs.
But spec. says that
1*) If the bean is dependent scope and remove method is called, "Call ejb remove
method with EMPTY parameters" (this is only occured in our case with item-3 i.e,
but destruction of ejb instance is delayed to destroy phase, I think this is not
correct. We have to call remove method of the EJB at the time call is made)
2*) When the bean is destroyed, if the bean is dependent and removed already via
1, do nothing else "container internally removes the bean instance". (In our
case, we do nothing on non-dependent scopes, I think this is not correct, we
also have to call internal remove method of the container)
WDYT?
Gurkan
Re: EJB Bean Stateful Bean Remove Methods
Posted by Eric Covener <co...@gmail.com>.
>>>>In a destroy() method is is still possible to check the context to
>>>>>make sure we actually obtained an EJB?
> We have to get an EJB instance under proxy to call remove method. What is you
> concern here?
My concern was to make sure we didn't cause one to be created just to
remove it -- in such a case where the method invocation handler was
never invoked and never actually obtained an EJB.
I think all is well though.
--
Eric Covener
covener@gmail.com
Re: EJB Bean Stateful Bean Remove Methods
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>We do not stop the direct invocation here -- we note it and allow the
>>>>call to flow through.
OK.
>>>>I don't understand this requirement in practice -- currently we do let
>>>>the remove method be called when it's invoked in the
>>>>EJBBeanProxyHandler, then we stop tracking it.
Me too.
>>>In a destroy() method is is still possible to check the context to
>>>>make sure we actually obtained an EJB?
We have to get an EJB instance under proxy to call remove method. What is you
concern here?
--Gurkan
________________________________
From: Eric Covener <co...@gmail.com>
To: dev@openwebbeans.apache.org
Sent: Thu, August 19, 2010 2:07:04 PM
Subject: Re: EJB Bean Stateful Bean Remove Methods
On Thu, Aug 19, 2010 at 3:05 AM, Gurkan Erdogdu <gu...@yahoo.com> wrote:
> Hi;
>
> I am trying to understand the current implementation in our
EjbBeanProxyHandler
> and BaseEJBBeans.
>
>
> If I understand correctly,
>
> 1*) BaseEjbBeans hold map : proxy --> dependent EJB stateful instance
> 2*) When a call is made to remove method of the stateful instance and bean is
> dependent scope, then remove "dependent EJB stateful instance" from
>BaseEJBBean
> "map" and do nothing
We do not stop the direct invocation here -- we note it and allow the
call to flow through.
> 3*) When the bean is destroyed and if it is dependent, then call Remove method
> of the stateful instance over container. But if the stateful is removed from
>map
> via item-2, then no remove method invocation occurs.
>
>
> But spec. says that
> 1*) If the bean is dependent scope and remove method is called, "Call ejb
>remove
> method with EMPTY parameters" (this is only occured in our case with item-3
>i.e,
> but destruction of ejb instance is delayed to destroy phase, I think this is
>not
> correct. We have to call remove method of the EJB at the time call is made)
I don't understand this requirement in practice -- currently we do let
the remove method be called when it's invoked in the
EJBBeanProxyHandler, then we stop tracking it.
Should we really step between the caller and the container and somehow
remove parameters?
> 2*) When the bean is destroyed, if the bean is dependent and removed already
>via
> 1, do nothing else "container internally removes the bean instance". (In our
> case, we do nothing on non-dependent scopes, I think this is not correct, we
> also have to call internal remove method of the container)
>
Yes this one looks busted, for normal scopes we should be causing the
instance to be removed by the container unconditionally in
Contextual.destroy(), since we always blocked the user from calling
it.
In a destroy() method is is still possible to check the context to
make sure we actually obtained an EJB?
--
Eric Covener
covener@gmail.com
Re: EJB Bean Stateful Bean Remove Methods
Posted by Eric Covener <co...@gmail.com>.
On Thu, Aug 19, 2010 at 3:05 AM, Gurkan Erdogdu <gu...@yahoo.com> wrote:
> Hi;
>
> I am trying to understand the current implementation in our EjbBeanProxyHandler
> and BaseEJBBeans.
>
>
> If I understand correctly,
>
> 1*) BaseEjbBeans hold map : proxy --> dependent EJB stateful instance
> 2*) When a call is made to remove method of the stateful instance and bean is
> dependent scope, then remove "dependent EJB stateful instance" from BaseEJBBean
> "map" and do nothing
We do not stop the direct invocation here -- we note it and allow the
call to flow through.
> 3*) When the bean is destroyed and if it is dependent, then call Remove method
> of the stateful instance over container. But if the stateful is removed from map
> via item-2, then no remove method invocation occurs.
>
>
> But spec. says that
> 1*) If the bean is dependent scope and remove method is called, "Call ejb remove
> method with EMPTY parameters" (this is only occured in our case with item-3 i.e,
> but destruction of ejb instance is delayed to destroy phase, I think this is not
> correct. We have to call remove method of the EJB at the time call is made)
I don't understand this requirement in practice -- currently we do let
the remove method be called when it's invoked in the
EJBBeanProxyHandler, then we stop tracking it.
Should we really step between the caller and the container and somehow
remove parameters?
> 2*) When the bean is destroyed, if the bean is dependent and removed already via
> 1, do nothing else "container internally removes the bean instance". (In our
> case, we do nothing on non-dependent scopes, I think this is not correct, we
> also have to call internal remove method of the container)
>
Yes this one looks busted, for normal scopes we should be causing the
instance to be removed by the container unconditionally in
Contextual.destroy(), since we always blocked the user from calling
it.
In a destroy() method is is still possible to check the context to
make sure we actually obtained an EJB?
--
Eric Covener
covener@gmail.com