Re: EJB contextual reference (our proxy) in creationalContext instead of instance?
I'm still confused by this. Do you agree terminology wise that our own javasist proxy is a contextual reference and that the proxy from EJB is our (underlying) contextual instance? Yes. For EJB at least, wouldn't keeping the contextual reference instead of the instance cause us to go create EJB's from our context just in order to @Remove them? I All of the things are done using contextual reference, including calling @Remove. Thing is that Altough it is someway ridicilous, any method is called follows the below execution path, Context Ref -- EJB Proxy Instance -- EJB Instance Gurkan From: Eric Covener cove...@gmail.com To: dev@openwebbeans.apache.org Sent: Sun, July 18, 2010 6:19:39 PM Subject: Re: EJB contextual reference (our proxy) in creationalContext instead of instance? On Sat, Jul 17, 2010 at 6:37 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: I think that in your case : RequestScope is ended and @RequestScoped bean is destroyed by the container. When this bean instance is destroyed by the container, container collects all of its dependencies from CreationalContextImpl and destroy all of them. In your case, it seems that this is the Stateful EJB instance dependency. To destroy stateful instance, container calls remove method. I'm still confused by this. Do you agree terminology wise that our own javasist proxy is a contextual reference and that the proxy from EJB is our (underlying) contextual instance? The latter may or may not need to be created, based on whether the injected reference is actually used. But it seems like we store the contextual reference itself, instead of the instance, in the dependent creational context. For EJB at least, wouldn't keeping the contextual reference instead of the instance cause us to go create EJB's from our context just in order to @Remove them? I am not sure if other bean types have enough going on in the destroyComponentInstance to care too much. I may be way off in left field, as I am struggling with trying to get my head around the code. Any illumination you could provide is much appreciated! at org.apache.webbeans.sample.ejb.Echo_$$_javassist_3.remove(Echo_$$_javassist_3.java) at org.apache.webbeans.util.ClassUtil.callInstanceMethod(ClassUtil.java:533) at org.apache.webbeans.ejb.common.component.BaseEjbBean.destroyComponentInstance(BaseEjbBean.java:149) at org.apache.webbeans.component.AbstractInjectionTargetBean.destroyInstance(AbstractInjectionTargetBean.java:179) at org.apache.webbeans.component.AbstractOwbBean.destroyCreatedInstance(AbstractOwbBean.java:265) at org.apache.webbeans.portable.creation.InjectionTargetProducer.preDestroy(InjectionTargetProducer.java:135) at org.apache.webbeans.component.InjectionTargetWrapper.preDestroy(InjectionTargetWrapper.java:104) at org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:219) at org.apache.webbeans.context.creational.CreationalContextImpl.removeDependents(CreationalContextImpl.java:278) at org.apache.webbeans.context.creational.CreationalContextImpl.release(CreationalContextImpl.java:349) at org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:232) at org.apache.webbeans.sample.ejb.Echo_$$_javassist_3.remove(Echo_$$_javassist_3.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.apache.webbeans.util.ClassUtil.callInstanceMethod(ClassUtil.java:533) at org.apache.webbeans.ejb.common.component.BaseEjbBean.destroyComponentInstance(BaseEjbBean.java:149) at org.apache.webbeans.component.AbstractInjectionTargetBean.destroyInstance(AbstractInjectionTargetBean.java:179) -- Eric Covener cove...@gmail.com
Re: ... then no parameters are passed to the method by the container
You are so right that Spec is not so clear about those kind of statements --Gurkan From: Eric Covener cove...@gmail.com To: dev@openwebbeans.apache.org Sent: Mon, July 19, 2010 3:26:38 AM Subject: ... then no parameters are passed to the method by the container 3.2.1 If the application directly calls an EJB remove method of a contextual instance of a session bean that is a stateful session bean and has scope @Dependent then no parameters are passed to the method by the container How can the container opt to not pass parameters to a remove method (whose signature has parameters) called by the application? -- Eric Covener cove...@gmail.com
[jira] Created: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers --- Key: OWB-406 URL: https://issues.apache.org/jira/browse/OWB-406 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-1 Environment: OWB + tomcat EJB integration Reporter: Eric Covener Assignee: Gurkan Erdogdu BaseEjbBean.removedStatefulInstance is used by MethodHandlers to track when a remove method on a session bean has been called, but there is only one one of these Contextuals per bean class not per instance. BaseEjbBean needs to manitain a map or the tracking needs to move into the Method Handler (EjbBeanProxyHandler) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-407) detailed information about exceptions
detailed information about exceptions - Key: OWB-407 URL: https://issues.apache.org/jira/browse/OWB-407 Project: OpenWebBeans Issue Type: Improvement Reporter: Gerhard Petracek Assignee: Gurkan Erdogdu owb should provide more information in case of invalid constellations. e.g. UnproxyableResolutionException shows way to few information about the real problem. all required information would be available (in this case in WebBeansUtil#checkUnproxiableApiType). detailed information about exceptions would help a lot during dev.-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-408) NPE in WebBeansELResolver
NPE in WebBeansELResolver - Key: OWB-408 URL: https://issues.apache.org/jira/browse/OWB-408 Project: OpenWebBeans Issue Type: Bug Reporter: Gerhard Petracek Assignee: Gurkan Erdogdu OwbElContextListener gets called in combination with myfaces-core but it's ignored in combination with mojarra (tested with mojarra 2). that leads to a NPE in WebBeansELResolver (there is no instance of ELContextStore) even though it looks like an issue of mojarra it would be nice to have a fallback or a completely different solution for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: JCDI and Bean Validation TCKs
If you have any thoughts, post 'em! :) Begin forwarded message: Resent-From: dblev...@visi.com From: David Blevins david.blev...@visi.com Date: July 19, 2010 9:44:53 PM PDT To: d...@geronimo.apache.org Subject: JCDI and Bean Validation TCKs Reply-To: d...@geronimo.apache.org Currently we have these setup in the private svn where the Java EE TCK porting modules live. The JCDI and Bean Validation TCKs are public Apache licensed, so we could move the porting modules for those two TCKs into our public svn. The part of my brain that finds esthetic pleasure in filling cabinets likes everything all organized in the one VM, but the part of me that likes to be more public than private thinks it's unnecessarily restrictive to make people sign the Sun/Apache NDA to get access to things not under that restriction. Specifically, everyone in the related communities (OpenWebBeans, OpenEJB) could easily access the public TCKs. Mark and Gurkan fall into that category now. Both are in the process of getting NDAs filled, but we could definitely speed that up by opening the porting code to the public. We might even be able to work the JCDI and Bean Validation into our larger test suite right in the main build as they only take a moments to run. Thoughts? -David
