On Thu, Aug 19, 2010 at 3:05 AM, Gurkan Erdogdu <gurkanerdo...@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
cove...@gmail.com

Reply via email to