[jira] Commented: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
[ https://issues.apache.org/jira/browse/OWB-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906684#action_12906684 ] Gurkan Erdogdu commented on OWB-447: Method invocations on non-contextual EJB's must be decoratable Where this requirement is specified? AFAIK, decroations are available for CDI-299 beans, not for non-contextuals unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor --- Key: OWB-447 URL: https://issues.apache.org/jira/browse/OWB-447 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 16h Remaining Estimate: 16h The separation between contextual and non-contextual is wrong/harmful and unnecessary. * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes * We should not rely on the thread-locals beyond @PostConstruct * Method invocations on non-contextual EJB's must be decoratable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
[ https://issues.apache.org/jira/browse/OWB-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906685#action_12906685 ] Gurkan Erdogdu commented on OWB-447: * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes Where you see the problem? We managed CeationalContext per instance that also contains interceptors and other dependents. We should not rely on the thread-locals beyond @PostConstruct ? What is the problem that you see? unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor --- Key: OWB-447 URL: https://issues.apache.org/jira/browse/OWB-447 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 16h Remaining Estimate: 16h The separation between contextual and non-contextual is wrong/harmful and unnecessary. * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes * We should not rely on the thread-locals beyond @PostConstruct * Method invocations on non-contextual EJB's must be decoratable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-445) we must not use javassist ProxyFactory#setHandler(MethodHandler)
[ https://issues.apache.org/jira/browse/OWB-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-445: -- Fix Version/s: 1.0.0-alpha-3 we must not use javassist ProxyFactory#setHandler(MethodHandler) Key: OWB-445 URL: https://issues.apache.org/jira/browse/OWB-445 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Mark Struberg Assignee: Joe Bergmark Fix For: 1.0.0-alpha-3 ProxyFactory.setHandler is deprecated and if used creates memory leaks! We must create the ProxyClass without a default method handler and set it after we create a proxy instance of that very class: Object proxyInstance = proxyClass.newInstance(); ((ProxyObject) proxyInstance ).setHandler( ... ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
[ https://issues.apache.org/jira/browse/OWB-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906766#action_12906766 ] Eric Covener commented on OWB-447: -- Method invocations on non-contextual EJB's must be decoratable Where this requirement is specified? AFAIK, decroations are available for CDI-299 beans, not for non-contextuals the clauses in 7.2 add up to decoratable EJB business method calls even when not made through a contextual reference. unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor --- Key: OWB-447 URL: https://issues.apache.org/jira/browse/OWB-447 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 16h Remaining Estimate: 16h The separation between contextual and non-contextual is wrong/harmful and unnecessary. * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes * We should not rely on the thread-locals beyond @PostConstruct * Method invocations on non-contextual EJB's must be decoratable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
[ https://issues.apache.org/jira/browse/OWB-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-447. -- Resolution: Fixed * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes Where you see the problem? We managed CeationalContext per instance that also contains interceptors and other dependents. I think they are an unnecessary complication, and I believe there is a problem at least with stateless session beans. In this case EJB interceptors live for the life of the bean even as it goes in and out of the pool, but we'll be swapping the thread-local CC in and out (and also swapping contextual and non-contextual references to the same stateful bean which means the same OWB interceptor -- it becomes impossible to really know the significance of the thread local) Since the container is carefully managing the life of the intereptor itself, we should be able to piggyback on this and and use PostConstruct/PreDestroy to manage a CC for the life of the interceptor. We should not rely on the thread-locals beyond @PostConstruct ? What is the problem that you see? This is more of a simplification. My original issue that led me down this path was errors deserializing our openwebbeansejbinterceptor but I think that was due to storing references to the underlying EJB instance. This change is more of a side-effect of making contextual/non-contextual a single path outside of @PostConstruct. unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor --- Key: OWB-447 URL: https://issues.apache.org/jira/browse/OWB-447 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 16h Remaining Estimate: 16h The separation between contextual and non-contextual is wrong/harmful and unnecessary. * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes * We should not rely on the thread-locals beyond @PostConstruct * Method invocations on non-contextual EJB's must be decoratable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-448) More changes for decorator and interceptor passivation support
More changes for decorator and interceptor passivation support -- Key: OWB-448 URL: https://issues.apache.org/jira/browse/OWB-448 Project: OpenWebBeans Issue Type: Improvement Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-2 Reporter: YING WANG Assignee: YING WANG Priority: Minor Fix For: 1.0.0-alpha-3 add some serialization/deserialization code for interceptor, decorator, and @EJB and some of their handlers. Note: due to the nature of abstract decorator and javassist (we use a proxy object to instanciate the abstract decorator class. ), passivation of abstract decorator is not working right now since the fields in the decorator((proxy object) could not be serialzed by javassist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-448) More changes for decorator and interceptor passivation support
[ https://issues.apache.org/jira/browse/OWB-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906853#action_12906853 ] Mark Struberg commented on OWB-448: --- please note that the abstract decorator proxy stuff is currently broken! We _must_ _not_ use ProxyFactors#setHandler(MethodHandler) and instead set the MethodHandler to each ProxyObject! More changes for decorator and interceptor passivation support -- Key: OWB-448 URL: https://issues.apache.org/jira/browse/OWB-448 Project: OpenWebBeans Issue Type: Improvement Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-2 Reporter: YING WANG Assignee: YING WANG Priority: Minor Fix For: 1.0.0-alpha-3 add some serialization/deserialization code for interceptor, decorator, and @EJB and some of their handlers. Note: due to the nature of abstract decorator and javassist (we use a proxy object to instanciate the abstract decorator class. ), passivation of abstract decorator is not working right now since the fields in the decorator((proxy object) could not be serialzed by javassist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-449) EJB interceptor has incorrect/unnecessary use of business method checks
EJB interceptor has incorrect/unnecessary use of business method checks --- Key: OWB-449 URL: https://issues.apache.org/jira/browse/OWB-449 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor EJB interceptor checks in its own @AroundInvoke whether the method is a business method but it: *) only considers local interfaces, but remote and bean-local view methods must be interceptable (whether or not they are 299 bean-types) *) is unnecessary since the EJB container only calls this @AroundInvoke for business method invocations Also, the warning for Object.class methods is duplicated in the @AroundInvoke and our EJBBeanProxyHandler. I think we should remove it from the former, since it only applies to contextual reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-449) EJB interceptor has incorrect/unnecessary use of business method checks
[ https://issues.apache.org/jira/browse/OWB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-449. -- Resolution: Fixed EJB interceptor has incorrect/unnecessary use of business method checks --- Key: OWB-449 URL: https://issues.apache.org/jira/browse/OWB-449 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Original Estimate: 1h Remaining Estimate: 1h EJB interceptor checks in its own @AroundInvoke whether the method is a business method but it: *) only considers local interfaces, but remote and bean-local view methods must be interceptable (whether or not they are 299 bean-types) *) is unnecessary since the EJB container only calls this @AroundInvoke for business method invocations Also, the warning for Object.class methods is duplicated in the @AroundInvoke and our EJBBeanProxyHandler. I think we should remove it from the former, since it only applies to contextual reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-445) we must not use javassist ProxyFactory#setHandler(MethodHandler)
[ https://issues.apache.org/jira/browse/OWB-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906961#action_12906961 ] Joe Bergmark commented on OWB-445: -- I'll take a look. I seem to remember the AbstractDecorator case is difficult, as we have the information we need at deploy time to create the Proxy class and place that constructor back into the ManagedBean. I don't know if we have any hook to do this at runtime. we must not use javassist ProxyFactory#setHandler(MethodHandler) Key: OWB-445 URL: https://issues.apache.org/jira/browse/OWB-445 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Mark Struberg Assignee: Joe Bergmark Fix For: 1.0.0-alpha-3 ProxyFactory.setHandler is deprecated and if used creates memory leaks! We must create the ProxyClass without a default method handler and set it after we create a proxy instance of that very class: Object proxyInstance = proxyClass.newInstance(); ((ProxyObject) proxyInstance ).setHandler( ... ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-450) NullPointerException in DependentScopedBeanInterceptorHandler when it has a NullCreationalContext (normally from a EE component).
NullPointerException in DependentScopedBeanInterceptorHandler when it has a NullCreationalContext (normally from a EE component). - Key: OWB-450 URL: https://issues.apache.org/jira/browse/OWB-450 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Joe Bergmark Assignee: Joe Bergmark Fix For: 1.0.0-alpha-3 DependentScopedBeanInterceptorHandler throws a NullPointerException in the constructor if the creational context passed in returns null for getBean(). I believe when EE components create a null creational context getBean() will return null. Section 11.3.3 of the CDI spec talks about passing in a null for non-contextual objects. A quick fix will be to check for null before trying to compare the ccImpl.getBean() to the bean passed into the constructor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
[ https://issues.apache.org/jira/browse/OWB-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907018#action_12907018 ] Eric Covener commented on OWB-447: -- re: referencing thread-locals beyond @PostConstrut, we already need to do _something_ different since the threadlocal CC will be lost during serialization. One option then is to spill this into a local variable in @PostConstruct, but going down this path it becomes clear to me that the better scheme is to create a CC in @PostConstruct and use it for all intereptors/decorators. This exploits the fact that the EJB container calls @PostConstrut/@PreDestroy quite carefully depending on the lifecyle of the underlying EJB. unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor --- Key: OWB-447 URL: https://issues.apache.org/jira/browse/OWB-447 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 16h Remaining Estimate: 16h The separation between contextual and non-contextual is wrong/harmful and unnecessary. * We should be managing a CreationalContext for the lifetime of the interceptor instance and using that for dependent instanes * We should not rely on the thread-locals beyond @PostConstruct * Method invocations on non-contextual EJB's must be decoratable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
