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
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
[jira] Resolved: (OWB-442) our EJB proxies are broken when multiple local interfaces are used on a single class
[ https://issues.apache.org/jira/browse/OWB-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-442. -- Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed our EJB proxies are broken when multiple local interfaces are used on a single class Key: OWB-442 URL: https://issues.apache.org/jira/browse/OWB-442 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 2h Remaining Estimate: 2h our javassist proxies for EJB beans only implement the single injected type, but they are stored in a cache keyed solely off the managed bean class. We need either another dimension for the type, or to set all local interfaces on the proxy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EJB Bean Stateful Bean Remove Methods
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 cove...@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 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
Re: EJB Bean Stateful Bean Remove Methods
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 cove...@gmail.com
[jira] Resolved: (OWB-443) Normal-scoped EJB not removed by container during Contextual.destroy()
[ https://issues.apache.org/jira/browse/OWB-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-443. -- Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed Normal-scoped EJB not removed by container during Contextual.destroy() -- Key: OWB-443 URL: https://issues.apache.org/jira/browse/OWB-443 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 1h Remaining Estimate: 1h Normal-scoped EJB not removed by container during Contextual.destroy() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
