[jira] [Commented] (OWB-771) Invocation​ContextImpl cleans target field if occurs an exception
[
https://issues.apache.org/jira/browse/OWB-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13577118#comment-13577118
]
Eric Covener commented on OWB-771:
--
I don't think this assignment accomplishes much, the InvocationContextImpl will
not be alive very much longer anyway. Unit tests and TCK don't mind -- any
concerns with removing both assignments?
Invocation​ContextImpl cleans target field if occurs an exception
-
Key: OWB-771
URL: https://issues.apache.org/jira/browse/OWB-771
Project: OpenWebBeans
Issue Type: Bug
Components: Core, Interceptor and Decorators
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7
Reporter: Thiago Soares
Priority: Trivial
I've done some tests using ApacheOpenWebBeans 1.1.x as the CDI implementation.
I am using a Framework (frameworkdemoiselle.gov.br) that offers an
interceptor that handles exceptions thrown by the target bean.
A summary of this interceptor is written bellow:
=
@AroundInvoke
public Object manage(final InvocationContext ic) throws Exception {
Object result = null;
try {
result = ic.proceed();
} catch (Exception cause) {
// Handle Exception here
target = ic.getTarget();
...
}
return result;
}
=
The Handle Exception logic uses the target bean. The problem is that
the ic.getTarget() method returns null and i get a
NullPointerException.
I've done the same test using WELD and ic.getTarget() does not returns null.
Analyzing the source code of the class
org.apache.webbeans.intercept.InvocationContextImpl I see that it
destroys the target instance when it catches an exception.
=
public Object proceed() throws Exception
{
try
{
if (type.equals(InterceptionType.AROUND_INVOKE))
{
return proceedAroundInvokes(interceptorDatas);
}
else if (type.equals(InterceptionType.AROUND_TIMEOUT))
{
return proceedAroundTimeouts(interceptorDatas);
}
return proceedCommonAnnots(interceptorDatas, type);
}
catch (InvocationTargetException ite)
{
target = null; // destroy target instance=
// Try to provide the original exception to the interceptor stack,
// not the InvocationTargetException from Method.invoke
Throwable t = ite.getCause();
if (t instanceof Exception)
{
throw (Exception) t;
}
throw ite;
}
catch (Exception e)
{
target = null; // destroy target instance =
throw e;
}
}
=
My question is: Why we need to destroy the target instance when occurs
an Exception? Doing it so, the interceptor cannot get the target after
invoking proceed() method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OWB-568) Decorater for generic Interfaces does not work
[ https://issues.apache.org/jira/browse/OWB-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener updated OWB-568: - Attachment: owb-trunk-generic_decorator.diff I took the approach of removing types from the bean types of the decorator rather than trying to duplicate the hairy generic stuff. This passes the disabled test and the TCK Decorater for generic Interfaces does not work -- Key: OWB-568 URL: https://issues.apache.org/jira/browse/OWB-568 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: 1.1.0 Reporter: Arne Limburg Assignee: Mark Struberg Fix For: 1.2.0 Attachments: OWB-568.patch, OWB-568.zip, owb-trunk-generic_decorator.diff When a Decorator implements an interface with a generic type argument, the check to compare the decorator type and the type of the delegate injection point always fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-738) CODI @ConversationScope + @Stateful in a bean = java.lang.StackOverflowError
[
https://issues.apache.org/jira/browse/OWB-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13533043#comment-13533043
]
Eric Covener commented on OWB-738:
--
AFAICT WSEjbBean is calling Context.get with no CreationalContext to test if an
instance is already in the scope, but it looks like the custom scope is trying
to create a new instance, which si where it then loops.
The get() method may not create a new instance of the given contextual type
unless a CreationalContext is given.
CODI @ConversationScope + @Stateful in a bean = java.lang.StackOverflowError
-
Key: OWB-738
URL: https://issues.apache.org/jira/browse/OWB-738
Project: OpenWebBeans
Issue Type: Bug
Affects Versions: 1.1.6
Environment: WebSphere v8.5.0.1 on Windows
Reporter: Denis Forveille
In WebSphere v8.5.0.1 this very simple bean causes a
java.lang.StackOverflowError :
@Named(codiTestConversationCtrl)
@ConversationScoped
@Stateful
public class CODITestConversationCtrl implements Serializable {
private static final long serialVersionUID = 1L;
private Integer valeur;
whatever code from here, getters/setters etc
It is simply referenced in a page with
#{codiTestConversationCtrl.valeur}
This causes a StackOverflowError after an endless recursive loop .
If i use the CDI @ConversationScoped standard annotation instead of the CODI
one, it works
If I remove the @Stateful annotation to use a plain POJO instead of a SFSB,
it works too..
Check the initial diagnostic by Gerhard Petracek from the Apache CODI
project there : https://issues.apache.org/jira/browse/EXTCDI-304
Here are some part of the traceback:
...
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:174)
at
org.apache.webbeans.container.SerializableBean.create(SerializableBean.java:128)
at
org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.createNewInstanceOfBean(CodiUtils.java:69)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.createNewBeanInstance(AbstractConversationBeanEntry.java:139)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.getBeanInstance(AbstractConversationBeanEntry.java:84)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultConversation.getBean(DefaultConversation.java:163)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanInstance(GroupedConversationContext.java:185)
at
org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.AbstractGroupedConversationContext.resolve(AbstractGroupedConversationContext.java:114)
at
org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.ConversationContextAdapter.get(ConversationContextAdapter.java:98)
at
org.apache.webbeans.context.CustomContextImpl.get(CustomContextImpl.java:48)
at
org.apache.webbeans.context.CustomPassivatingContextImpl.get(CustomPassivatingContextImpl.java:47)
at
org.apache.webbeans.ejb.component.WSEjbBean.getInstance(WSEjbBean.java:196)
at
org.apache.webbeans.ejb.common.component.BaseEjbBean.createComponentInstance(BaseEjbBean.java:104)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.createDefaultInstance(AbstractInjectionTargetBean.java:134)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.createInstance(AbstractInjectionTargetBean.java:117)
at
org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:216)
at
org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:82)
at
org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:145)
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:174)
at
org.apache.webbeans.container.SerializableBean.create(SerializableBean.java:128)
at
org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.createNewInstanceOfBean(CodiUtils.java:69)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.createNewBeanInstance(AbstractConversationBeanEntry.java:139)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.getBeanInstance(AbstractConversationBeanEntry.java:84)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultConversation.getBean(DefaultConversation.java:163)
at
[jira] [Commented] (OWB-738) CODI @ConversationScope + @Stateful in a bean = java.lang.StackOverflowError
[
https://issues.apache.org/jira/browse/OWB-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13533046#comment-13533046
]
Eric Covener commented on OWB-738:
--
The confusing part is why it needs to call Context.get when the scope just
called into Bean.getInstance() -- I don't know how this could ever return
non-null. It may be that there is some non-standard path into
Bean.getInstance() in WAS that means we can get in here w/ a context active in
the scope.
CODI @ConversationScope + @Stateful in a bean = java.lang.StackOverflowError
-
Key: OWB-738
URL: https://issues.apache.org/jira/browse/OWB-738
Project: OpenWebBeans
Issue Type: Bug
Affects Versions: 1.1.6
Environment: WebSphere v8.5.0.1 on Windows
Reporter: Denis Forveille
In WebSphere v8.5.0.1 this very simple bean causes a
java.lang.StackOverflowError :
@Named(codiTestConversationCtrl)
@ConversationScoped
@Stateful
public class CODITestConversationCtrl implements Serializable {
private static final long serialVersionUID = 1L;
private Integer valeur;
whatever code from here, getters/setters etc
It is simply referenced in a page with
#{codiTestConversationCtrl.valeur}
This causes a StackOverflowError after an endless recursive loop .
If i use the CDI @ConversationScoped standard annotation instead of the CODI
one, it works
If I remove the @Stateful annotation to use a plain POJO instead of a SFSB,
it works too..
Check the initial diagnostic by Gerhard Petracek from the Apache CODI
project there : https://issues.apache.org/jira/browse/EXTCDI-304
Here are some part of the traceback:
...
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:174)
at
org.apache.webbeans.container.SerializableBean.create(SerializableBean.java:128)
at
org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.createNewInstanceOfBean(CodiUtils.java:69)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.createNewBeanInstance(AbstractConversationBeanEntry.java:139)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.getBeanInstance(AbstractConversationBeanEntry.java:84)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultConversation.getBean(DefaultConversation.java:163)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanInstance(GroupedConversationContext.java:185)
at
org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.AbstractGroupedConversationContext.resolve(AbstractGroupedConversationContext.java:114)
at
org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.ConversationContextAdapter.get(ConversationContextAdapter.java:98)
at
org.apache.webbeans.context.CustomContextImpl.get(CustomContextImpl.java:48)
at
org.apache.webbeans.context.CustomPassivatingContextImpl.get(CustomPassivatingContextImpl.java:47)
at
org.apache.webbeans.ejb.component.WSEjbBean.getInstance(WSEjbBean.java:196)
at
org.apache.webbeans.ejb.common.component.BaseEjbBean.createComponentInstance(BaseEjbBean.java:104)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.createDefaultInstance(AbstractInjectionTargetBean.java:134)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.createInstance(AbstractInjectionTargetBean.java:117)
at
org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:216)
at
org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:82)
at
org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:145)
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:174)
at
org.apache.webbeans.container.SerializableBean.create(SerializableBean.java:128)
at
org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.createNewInstanceOfBean(CodiUtils.java:69)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.createNewBeanInstance(AbstractConversationBeanEntry.java:139)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.AbstractConversationBeanEntry.getBeanInstance(AbstractConversationBeanEntry.java:84)
at
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultConversation.getBean(DefaultConversation.java:163)
at
[jira] [Updated] (OWB-479) detect loops in producer beans vs. producer method parameters at deployment time
[ https://issues.apache.org/jira/browse/OWB-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener updated OWB-479: - Fix Version/s: 1.2.0 detect loops in producer beans vs. producer method parameters at deployment time Key: OWB-479 URL: https://issues.apache.org/jira/browse/OWB-479 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Gurkan Erdogdu Priority: Minor Fix For: 1.2.0 Currently OWB can cause a stack overflow if a parameter on a producer method is satisfied by the same bean as the producer method itself, it would be nice if we could trap such a thing in producer beans at deployment time and minimally warn about the offending method/parameter. at org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723) at org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:134) at org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:117) at org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:193) at org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:155) at org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:208) at org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:82) at org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:142) at org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:166) at org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:69) at org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:191) at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:839) at org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OWB-488) move WebBeansConfigurationException messages to message bundles
[ https://issues.apache.org/jira/browse/OWB-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener updated OWB-488: - Fix Version/s: 1.2.0 move WebBeansConfigurationException messages to message bundles --- Key: OWB-488 URL: https://issues.apache.org/jira/browse/OWB-488 Project: OpenWebBeans Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Gurkan Erdogdu Fix For: 1.2.0 lots of grave WebBeansConfigurationException use string literals for stuff that ought to be translatable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OWB-488) move WebBeansConfigurationException messages to message bundles
move WebBeansConfigurationException messages to message bundles --- Key: OWB-488 URL: https://issues.apache.org/jira/browse/OWB-488 Project: OpenWebBeans Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Gurkan Erdogdu lots of grave WebBeansConfigurationException use string literals for stuff that ought to be translatable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-487) Section 5.5.7 restrictions on injecting InjectionPoint not enforced
[ https://issues.apache.org/jira/browse/OWB-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12926028#action_12926028 ] Eric Covener commented on OWB-487: -- I think this is best read as ... qualifiers @Default, @Any, and no other qualifiers which really means when the dependency will be satisfied by the containers built-in injection point. Section 5.5.7 restrictions on injecting InjectionPoint not enforced --- Key: OWB-487 URL: https://issues.apache.org/jira/browse/OWB-487 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Attachments: OWB-487.patch Section 5.5.7 ends with a couple restrictions on injecting InjectionPoint. Theres a tck test for one of them, an InjectionPoint in a servlet is not OK. text: f a bean that declares any scope other than @Dependent has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error. If a Java EE component class supporting injection that is not a bean has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error. test: org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.InjectionPointTest org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.TestServlet_Broken -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-485) AmbiguousResolutionException doesn't print details about the injection point
AmbiguousResolutionException doesn't print details about the injection point Key: OWB-485 URL: https://issues.apache.org/jira/browse/OWB-485 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.1.0 AmbiguousResolutionException doesn't print details about the injection point, which is important to debug the application. This is easy to add since the Unsatisfiable already prints the injection point details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-485) AmbiguousResolutionException doesn't print details about the injection point
[ https://issues.apache.org/jira/browse/OWB-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-485. -- Resolution: Fixed AmbiguousResolutionException doesn't print details about the injection point Key: OWB-485 URL: https://issues.apache.org/jira/browse/OWB-485 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.1.0 Original Estimate: 0.25h Remaining Estimate: 0.25h AmbiguousResolutionException doesn't print details about the injection point, which is important to debug the application. This is easy to add since the Unsatisfiable already prints the injection point details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-485) AmbiguousResolutionException doesn't print details about the injection point
[ https://issues.apache.org/jira/browse/OWB-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12925226#action_12925226 ] Eric Covener commented on OWB-485: -- thanks, got it in r1027789. AmbiguousResolutionException doesn't print details about the injection point Key: OWB-485 URL: https://issues.apache.org/jira/browse/OWB-485 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.1.0 Original Estimate: 0.25h Remaining Estimate: 0.25h AmbiguousResolutionException doesn't print details about the injection point, which is important to debug the application. This is easy to add since the Unsatisfiable already prints the injection point details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-479) detect loops in producer beans vs. producer method parameters at deployment time
detect loops in producer beans vs. producer method parameters at deployment time Key: OWB-479 URL: https://issues.apache.org/jira/browse/OWB-479 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: 1.0.0 Reporter: Eric Covener Assignee: Gurkan Erdogdu Priority: Minor Currently OWB can cause a stack overflow if a parameter on a producer method is satisfied by the same bean as the producer method itself, it would be nice if we could trap such a thing in producer beans at deployment time and minimally warn about the offending method/parameter. at org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723) at org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:134) at org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:117) at org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:193) at org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:155) at org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:208) at org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:82) at org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:142) at org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:166) at org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:69) at org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:191) at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:839) at org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:723) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-465) enhance EJB common code for crude @LocalBean support
[ https://issues.apache.org/jira/browse/OWB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-465. -- Resolution: Fixed enhance EJB common code for crude @LocalBean support Key: OWB-465 URL: https://issues.apache.org/jira/browse/OWB-465 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-GA Original Estimate: 1h Remaining Estimate: 1h I need a small enhancement to expose no-interface local views for EJB to the 299 Api Types. I am not sure if this is necessary for openejb, but in my containr the bean-class is not returned among the local business itnterfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-463) EjbDefinitionUtility.defineEjbBeanProxy() should be able to create proxies for no-interface local beans
[ https://issues.apache.org/jira/browse/OWB-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-463. -- Resolution: Fixed EjbDefinitionUtility.defineEjbBeanProxy() should be able to create proxies for no-interface local beans --- Key: OWB-463 URL: https://issues.apache.org/jira/browse/OWB-463 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-3 Original Estimate: 1h Remaining Estimate: 1h Sometimes callers of EjbDefinitionUtility.defineEjbBeanProxy() will have to pass the local bean class, when @LocalBean is the only valid local business interface. But, we can't pass the bean class to the proxyFactory.setInterfaces() as this causes an exeption in javassist since it's not really an interface that can be implemented. On my stack, I see Caused by: java.lang.RuntimeException: by java.lang.IncompatibleClassChangeError: foo.classWithLocalBeanView at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509) at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486) at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394) at org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301) at java.security.AccessController.doPrivileged(AccessController.java:202) at org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184) at org.apache.webbeans.proxy.JavassistProxyFactory.defineEjbBeanProxyClass(JavassistProxyFactory.java:149) at org.apache.webbeans.ejb.common.util.EjbDefinitionUtility.defineEjbBeanProxy(EjbDefinitionUtility.java:73) Simply calling proxyFactory.setSuperClass() seems sufficient and makes sense. -- 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=12913269#action_12913269 ] Eric Covener commented on OWB-447: -- I don't know how I managed it, but I marked this resolved on 9/7 but it's really resolved today with r999653 -- sorry 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-454) ClassUtil.callInstanceMethod() doesn't propogate original exception
ClassUtil.callInstanceMethod() doesn't propogate original exception Key: OWB-454 URL: https://issues.apache.org/jira/browse/OWB-454 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener ClassUtil.callInstanceMethod() doesn't propogate original exception up the stack -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-454) ClassUtil.callInstanceMethod() doesn't propogate original exception
[ https://issues.apache.org/jira/browse/OWB-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-454. -- Resolution: Fixed ClassUtil.callInstanceMethod() doesn't propogate original exception Key: OWB-454 URL: https://issues.apache.org/jira/browse/OWB-454 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Original Estimate: 0.25h Remaining Estimate: 0.25h ClassUtil.callInstanceMethod() doesn't propogate original exception up the stack -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-455) IllegalArgument method calling remove method of EJB during destroy
IllegalArgument method calling remove method of EJB during destroy -- Key: OWB-455 URL: https://issues.apache.org/jira/browse/OWB-455 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-alpha-3 Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class Some incompatability between the way we scan for remove methods up front vs. what's present in the EJB proxy we get. Long-term, we shouldn't call these anyway, but we can at least try to find the corresponding remove method on the EJB reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-453) add a flag to disable context activation in EJB interceptor
add a flag to disable context activation in EJB interceptor --- Key: OWB-453 URL: https://issues.apache.org/jira/browse/OWB-453 Project: OpenWebBeans Issue Type: Task Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-3 Some containers might activate contexts in some other way (another dedicated interceptor, or even something else), so make the OpenWebBeansEJBInterceptor conditionally look at the requests context. org.apache.webbeans.application.useEJBInterceptorActivation (true by default) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-318) multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances
[ https://issues.apache.org/jira/browse/OWB-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908101#action_12908101 ] Eric Covener commented on OWB-318: -- something wrong after applying the patch, mvn -Dtest=org.apache.webbeans.newtests.interceptors.business.tests.InterceptorPerformanceTest test gets 25x slower, seems like it's creating too many instanes multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances - Key: OWB-318 URL: https://issues.apache.org/jira/browse/OWB-318 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-1 Attachments: owb-318-patch.diff Original Estimate: 6h Remaining Estimate: 6h One managed bean with multiple methods with the same EJB @interceptors(foo.class) get multiple interceptor instances, but we should only create 1 instance. See TCK method org.jboss.jsr299.tck.interceptors.tests.method.MethodLevelInterceptorTest.testInterceptorCanBeAppliedToMoreThanOneMethod(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-318) multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances
[ https://issues.apache.org/jira/browse/OWB-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908118#action_12908118 ] Eric Covener commented on OWB-318: -- whoops, I had DEBUG logging set at JRE level for the unit test multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances - Key: OWB-318 URL: https://issues.apache.org/jira/browse/OWB-318 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-1 Attachments: owb-318-patch.diff Original Estimate: 6h Remaining Estimate: 6h One managed bean with multiple methods with the same EJB @interceptors(foo.class) get multiple interceptor instances, but we should only create 1 instance. See TCK method org.jboss.jsr299.tck.interceptors.tests.method.MethodLevelInterceptorTest.testInterceptorCanBeAppliedToMoreThanOneMethod(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-318) multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances
[ https://issues.apache.org/jira/browse/OWB-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-318. -- Fix Version/s: 1.0.0-alpha-3 (was: 1.0.0-alpha-1) Resolution: Fixed multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances - Key: OWB-318 URL: https://issues.apache.org/jira/browse/OWB-318 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-3 Attachments: owb-318-patch.diff Original Estimate: 6h Remaining Estimate: 6h One managed bean with multiple methods with the same EJB @interceptors(foo.class) get multiple interceptor instances, but we should only create 1 instance. See TCK method org.jboss.jsr299.tck.interceptors.tests.method.MethodLevelInterceptorTest.testInterceptorCanBeAppliedToMoreThanOneMethod(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OWB-318) multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances
[ https://issues.apache.org/jira/browse/OWB-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reopened OWB-318: -- reopening per Rohit multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances - Key: OWB-318 URL: https://issues.apache.org/jira/browse/OWB-318 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-1 Original Estimate: 6h Remaining Estimate: 6h One managed bean with multiple methods with the same EJB @interceptors(foo.class) get multiple interceptor instances, but we should only create 1 instance. See TCK method org.jboss.jsr299.tck.interceptors.tests.method.MethodLevelInterceptorTest.testInterceptorCanBeAppliedToMoreThanOneMethod(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-451) Allow InterceptorUtil#callAroundInvokes to propogate a callers 'creational context key'
Allow InterceptorUtil#callAroundInvokes to propogate a callers 'creational context key' --- Key: OWB-451 URL: https://issues.apache.org/jira/browse/OWB-451 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-alpha-3 For EJB's, it's handy to use a key into the dependentCreationalContext that is not the EJB's invocationContext.getTarget(). InterceptorUtil#callAroundInvokes should be able to take and pass along a key for its InvocationContext.setCcKey() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-451) Allow InterceptorUtil#callAroundInvokes to propogate a callers 'creational context key'
[ https://issues.apache.org/jira/browse/OWB-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-451. -- Resolution: Fixed Allow InterceptorUtil#callAroundInvokes to propogate a callers 'creational context key' --- Key: OWB-451 URL: https://issues.apache.org/jira/browse/OWB-451 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-alpha-3 Original Estimate: 0.5h Remaining Estimate: 0.5h For EJB's, it's handy to use a key into the dependentCreationalContext that is not the EJB's invocationContext.getTarget(). InterceptorUtil#callAroundInvokes should be able to take and pass along a key for its InvocationContext.setCcKey() -- 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-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-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.
[jira] Resolved: (OWB-446) EJB lifecycle callbacks not stacked correctly
[ https://issues.apache.org/jira/browse/OWB-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-446. -- Fix Version/s: 1.0.0-alpha-3 Resolution: Fixed EJB lifecycle callbacks not stacked correctly - Key: OWB-446 URL: https://issues.apache.org/jira/browse/OWB-446 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-3 Original Estimate: 1h Remaining Estimate: 1h * We call proceed() on the EJB invocation context even when some 299 interceptor may not have proceeded. * The defined-in-class lifecycle callback does not happen in the same stack as the 299 interceptors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-447) unnecessary contextual/non-contextual distinction in OpenWebBeansEJBIntercpetor
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 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=12906602#action_12906602 ] Eric Covener commented on OWB-447: -- we also need to avoid adding the underlying ejb instance (ejbcontext.getTarget()) as keys into dependent creational contexts. 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-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.
[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.
[jira] Created: (OWB-442) our EJB proxies are broken when multiple local interfaces are used on a single class
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 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.
[jira] Commented: (OWB-435) What is the expected result for following 2 decorators?
[
https://issues.apache.org/jira/browse/OWB-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898041#action_12898041
]
Eric Covener commented on OWB-435:
--
#1 seems like very wrong behavior
What is the expected result for following 2 decorators?
---
Key: OWB-435
URL: https://issues.apache.org/jira/browse/OWB-435
Project: OpenWebBeans
Issue Type: Question
Components: Interceptor and Decorators
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor
While I am testing 2 decorators decorate the same getName() method of
UserBean, I found the result is:
1. UserDecorator1(UserDecorator2(MYNAME))== Did call
UserDecorator1.getName() first, but before it finishes, it recursively
invokes the UserDecorator2.getName() on the calling stack.
2. or should the result be:
UserDecorator2(MYNAME) should decorator2's result overwrite
decorator1's?
3. or should the result be:
UserDecorator2(UserDecorator1(MYNAME)) should decorator1's result
to the one used for decorator2?
I prefer 3, but I am not sure which result is the correct one
===Userbean
public class UserBean implements UserInterface, Serializable
{
public String getName()
{
return MYNAME;
}
}
===UserDecorator1
@Decorator
public abstract class UserDecorator1 implements UserInterface, Serializable
{
@Inject @Delegate @Any UserInterface ui;
public String getName() {
return UserDecorator1( + ui.getName() + );
}
}
===UserDecorator2
@Decorator
public abstract class UserDecorator2 implements UserInterface, Serializable
{
@Inject @Delegate @Any UserInterface ui;
public String getName() {
return UserDecorator2( + ui.getName() + );
}
}
decorators
classcom.jcdi.test.UserDecorator1/class
classcom.jcdi.test.UserDecorator2/class
/decorators
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-431) Generic Type Inheritance not resolved correctly
[
https://issues.apache.org/jira/browse/OWB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893717#action_12893717
]
Eric Covener commented on OWB-431:
--
IMHO the spec could only have meant assignable from and not assignable to.
That would stop us from inverting the two types in question in our comparison:
If a producer produces T extends Pet (upper bound of Pet)
... and Pet extends Animal
... and Dog extends Pet.
Consider injection points:
@Inject @Default Dog d;
@Inject @Default Animal a;
When the spec says actual type is assignable to the upper bound I think they
MUST have intended
actual type is assignable _from_ the upper bound
I assume everyone agrees that the Animal injection is satisfiable (we can
produce a Pet, which is an Animal) and the Dog injection is not satisfiable:
Since the spec says actual type (Dog or Animal) is assignable _to_ the upper
bound (Pet) we reverse the arguments:
if (!Pet.isAssignableFrom(Dog)) { // wrong result, our code expects to call
dog.bark() but we're just producing a Pet!
return false;
}
if (!Pet.isAssignableFrom(Animal)) { // wrong result, Pet clearly fulfills
the injection point of Animal
return false;
}
But the real test for the injection point being satisfied should not be
reversed:
if (!Dog.isAssignableFrom(Pet)) { // we can't inject a pet into a field that
wants a dog
return false;
}
if (!Animal.isAssignableFrom(Pet)) { //
return false;
}
Generic Type Inheritance not resolved correctly
---
Key: OWB-431
URL: https://issues.apache.org/jira/browse/OWB-431
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: 1.0.0-alpha-1
Environment: standard OWB configuration
Reporter: Bill Wigger
Assignee: Gurkan Erdogdu
Priority: Minor
Fix For: 1.0.0-alpha-2
Attachments: ClassUtilPatch.txt, ClassUtilPatch2.txt
Original Estimate: 2h
Remaining Estimate: 2h
WebBean is defined as:
@Named
public class MethodTypeProduces1T extends Bc {
@Produces @Dependent @Named(ProMethodParameterized3) ArrayListT
methodPT3() {
and injected as:
@Named
@Dependent
public class ProMethodTestGroup3A {
public @Inject @Dependent @Named(ProMethodParameterized3)
ArrayListDc pt3;
with BC extending DC as follows:
public class Bc extends Dc implements Fi {
gives this error:
Jul 28, 2010 9:26:51 AM org.apache.webbeans.config.BeansDeployer deploy
SEVERE:
Throwable occurred: javax.enterprise.inject.UnsatisfiedResolutionException:
Api type [java.util.ArrayList] is not found with the qualifiers
[...@javax.inject.named(value=ProMethodParameterized3)] for injection into
Field Injection Point, field name : pt3, Bean Owner :
[Name:proMethodTestGroup3A,WebBeans Type:MANAGED,API
Types:[com.ibm.jcdi.test.ProMethodTestGroup3A,java.lang.Object],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]
at
org.apache.webbeans.container.ResolutionUtil.checkResolvedBeans(ResolutionUtil.java:121)
at
org.apache.webbeans.container.InjectionResolver.checkInjectionPoints(InjectionResolver.java:185)
at
org.apache.webbeans.container.BeanManagerImpl.validate(BeanManagerImpl.java:1025)
injection should be checked/resolved here in
org.apache.webbeans.util.ClassUtil, but this method returns false
public static boolean checkRequiredTypeIsClassAndBeanTypeIsVariable(Type
beanTypeArg, Type requiredTypeArg)
{
Class? clazzRequiredType = (Class?)requiredTypeArg;
TypeVariable? tvBeanTypeArg = (TypeVariable?)beanTypeArg;
Type tvBound = tvBeanTypeArg.getBounds()[0];
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzTvBound != Object.class)
{
if(!clazzTvBound.isAssignableFrom(clazzRequiredType))
{
return false;
}
}
}
return true;
}
But since clazzTvBound is Bc and classRequiredType is Dc
Bc.isAssignableFrom(Dc) returns false, so the ! is true, and the function
returns false.
fix seems to simply go back to the old code in this routine, this code was
changeed on 4/28, and
I can't see why is was changed.
But the check needs to verify that the required class can be assigned from
the given bean class, as follows:
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzRequiredType.isAssignableFrom(clazzTvBound))
{
return true;
}
[jira] Created: (OWB-421) defined-in-class EJB lifecycle callbacks masked by our Interceptor
defined-in-class EJB lifecycle callbacks masked by our Interceptor -- Key: OWB-421 URL: https://issues.apache.org/jira/browse/OWB-421 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener defined-in-class EJB lifecycle callbacks masked by our Interceptor, because we fail to call ejbContext.proceed() when we have no 299 lifecycle callbacks configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-421) defined-in-class EJB lifecycle callbacks masked by our Interceptor
[ https://issues.apache.org/jira/browse/OWB-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-421. -- Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed defined-in-class EJB lifecycle callbacks masked by our Interceptor -- Key: OWB-421 URL: https://issues.apache.org/jira/browse/OWB-421 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: 1h Remaining Estimate: 1h defined-in-class EJB lifecycle callbacks masked by our Interceptor, because we fail to call ejbContext.proceed() when we have no 299 lifecycle callbacks configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-418) EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB
EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB --- Key: OWB-418 URL: https://issues.apache.org/jira/browse/OWB-418 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Environment: tomcat+owb integration Reporter: Eric Covener Assignee: Eric Covener EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB, so the handler can maintain the required state. In other words, this should look more like the dependent interceptor handler. In the future, it might be nice to re-use handlers on other types of EJBs, but dependent SFSB is the most interesting with respect to 299 and has functional impact -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
[ https://issues.apache.org/jira/browse/OWB-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener closed OWB-406. Resolution: Fixed 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: Eric Covener Original Estimate: 4h Remaining Estimate: 4h 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] Closed: (OWB-415) EjbBeanProxyHandler for dependent ejb must save ejb instance
[ https://issues.apache.org/jira/browse/OWB-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener closed OWB-415. Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed EjbBeanProxyHandler for dependent ejb must save ejb instance - Key: OWB-415 URL: https://issues.apache.org/jira/browse/OWB-415 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 4h Remaining Estimate: 4h If we use a depenent EJB, the EjbBeanProxyHandler will try to acquire an EJB instance from the context each pass through the method handler. Multiple methods calls on the same injected proxy should be getting the same underlying EJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-416) BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods
[ https://issues.apache.org/jira/browse/OWB-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener closed OWB-416. Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods Key: OWB-416 URL: https://issues.apache.org/jira/browse/OWB-416 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: 1h Remaining Estimate: 1h BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods if they're available, but of course only the first remove method called can succeed -- after that the EJB container must have run the PreDestroy and invalidated the underlying EJB reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-418) EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB
[ https://issues.apache.org/jira/browse/OWB-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener closed OWB-418. Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB --- Key: OWB-418 URL: https://issues.apache.org/jira/browse/OWB-418 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Environment: tomcat+owb integration Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 4h Remaining Estimate: 4h EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB, so the handler can maintain the required state. In other words, this should look more like the dependent interceptor handler. In the future, it might be nice to re-use handlers on other types of EJBs, but dependent SFSB is the most interesting with respect to 299 and has functional impact -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
[ https://issues.apache.org/jira/browse/OWB-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reopened OWB-406: -- 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: Eric Covener Original Estimate: 4h Remaining Estimate: 4h 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] Resolved: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
[ https://issues.apache.org/jira/browse/OWB-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-406. -- Resolution: Fixed 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: Eric Covener Original Estimate: 4h Remaining Estimate: 4h 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] Reopened: (OWB-415) EjbBeanProxyHandler for dependent ejb must save ejb instance
[ https://issues.apache.org/jira/browse/OWB-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reopened OWB-415: -- EjbBeanProxyHandler for dependent ejb must save ejb instance - Key: OWB-415 URL: https://issues.apache.org/jira/browse/OWB-415 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 4h Remaining Estimate: 4h If we use a depenent EJB, the EjbBeanProxyHandler will try to acquire an EJB instance from the context each pass through the method handler. Multiple methods calls on the same injected proxy should be getting the same underlying EJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OWB-418) EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB
[ https://issues.apache.org/jira/browse/OWB-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reopened OWB-418: -- EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB --- Key: OWB-418 URL: https://issues.apache.org/jira/browse/OWB-418 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Environment: tomcat+owb integration Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 4h Remaining Estimate: 4h EjbBeanProxyHandler must be 1:1 with proxy instances for dependent SFSB, so the handler can maintain the required state. In other words, this should look more like the dependent interceptor handler. In the future, it might be nice to re-use handlers on other types of EJBs, but dependent SFSB is the most interesting with respect to 299 and has functional impact -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OWB-416) BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods
[ https://issues.apache.org/jira/browse/OWB-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reopened OWB-416: -- BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods Key: OWB-416 URL: https://issues.apache.org/jira/browse/OWB-416 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: 1h Remaining Estimate: 1h BaseEJBBean.destroyComponentInstance() tries to call multiple remove methods if they're available, but of course only the first remove method called can succeed -- after that the EJB container must have run the PreDestroy and invalidated the underlying EJB 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-415) EjbBeanProxyHandler for dependent ejb must save ejb instance
[ https://issues.apache.org/jira/browse/OWB-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-415. -- Resolution: Fixed EjbBeanProxyHandler for dependent ejb must save ejb instance - Key: OWB-415 URL: https://issues.apache.org/jira/browse/OWB-415 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-alpha-2 Original Estimate: 4h Remaining Estimate: 4h If we use a depenent EJB, the EjbBeanProxyHandler will try to acquire an EJB instance from the context each pass through the method handler. Multiple methods calls on the same injected proxy should be getting the same underlying EJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-415) EjbBeanProxyHandler for dependent ejb must save ejb instance
EjbBeanProxyHandler for dependent ejb must save ejb instance - Key: OWB-415 URL: https://issues.apache.org/jira/browse/OWB-415 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.0.0-alpha-1 Reporter: Eric Covener Assignee: Eric Covener If we use a depenent EJB, the EjbBeanProxyHandler will try to acquire an EJB instance from the context each pass through the method handler. Multiple methods calls on the same injected proxy should be getting the same underlying EJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-417) BaseEjbBean.destroyComponentInstance() should call direct container remove API, not call an @Remove annotated method
BaseEjbBean.destroyComponentInstance() should call direct container remove API, not call an @Remove annotated method Key: OWB-417 URL: https://issues.apache.org/jira/browse/OWB-417 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Reporter: Eric Covener Assignee: Gurkan Erdogdu BaseEjbBean.destroyComponentInstance() should call direct container remove API, not call an @Remove annotated method. When the destroy() method is called, and if the underlying EJB was not already removed by direct invocation of a remove method by the application, the container removes the stateful session bean. The @PreDestroy callback must be invoked by the container. Calling business methods with a side effect of the container removing the EJB does not seem to be what is intended. Completing this ticket requires an API in OpenEJB to remove a SFSB given just the reference the container gave us earlier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
[ https://issues.apache.org/jira/browse/OWB-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reassigned OWB-406: Assignee: Eric Covener (was: Gurkan Erdogdu) self-assigning, this ended up dovetailing into some related work 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: Eric Covener Original Estimate: 4h Remaining Estimate: 4h 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-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-401) ELContextStore not cleaned up for some JSP EL lookups
ELContextStore not cleaned up for some JSP EL lookups
-
Key: OWB-401
URL: https://issues.apache.org/jira/browse/OWB-401
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: M4
Environment: jetty + guess sample + simple dependent bean + jsp
Reporter: Eric Covener
Assignee: Gurkan Erdogdu
Playing with the guess sample with an added dependent bean and a JSP with a
simple EL expression referencing the same bean a few times results in 1
dependent bean instance being used for two expressions
openwebbeans.properties:
org.apache.webbeans.spi.adaptor.ELAdaptor=org.apache.webbeans.el10.EL10Adaptor
+org.apache.webbeans.application.jsp=true
added JSP:
c:out value=${dependentBean}/
c:out value=${dependentBean}/
This results in only one bean instance being created, because the first bean is
left in the thread-local ELContextStore for the 2nd expression.
Our current code counts on the ELResolver lookup being driven by our own
ELValueExpression, which gives us a chance to cleanup the thread-local context
on the way out, but this path goes right from jetty to our ELResolverCode twice
with no ValueExpression.
This seems to always work correctly from JSF, whether deferred evaluation is
used for the value or not. But this was only tested with the output mechanism
in login.xhtml so it may just be good/bad luck.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-401) ELContextStore not cleaned up for some JSP EL lookups
[
https://issues.apache.org/jira/browse/OWB-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881979#action_12881979
]
Eric Covener commented on OWB-401:
--
As I now understand it, the piece were missing is finding
container-specific/non-portable methods to wrap the JSP ExpressionFactory like
we do portably for JSF.
ELContextStore not cleaned up for some JSP EL lookups
-
Key: OWB-401
URL: https://issues.apache.org/jira/browse/OWB-401
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: M4
Environment: jetty + guess sample + simple dependent bean + jsp
Reporter: Eric Covener
Assignee: Gurkan Erdogdu
Original Estimate: 4h
Remaining Estimate: 4h
Playing with the guess sample with an added dependent bean and a JSP with a
simple EL expression referencing the same bean a few times results in 1
dependent bean instance being used for two expressions
openwebbeans.properties:
org.apache.webbeans.spi.adaptor.ELAdaptor=org.apache.webbeans.el10.EL10Adaptor
+org.apache.webbeans.application.jsp=true
added JSP:
c:out value=${dependentBean}/
c:out value=${dependentBean}/
This results in only one bean instance being created, because the first bean
is left in the thread-local ELContextStore for the 2nd expression.
Our current code counts on the ELResolver lookup being driven by our own
ELValueExpression, which gives us a chance to cleanup the thread-local
context on the way out, but this path goes right from jetty to our
ELResolverCode twice with no ValueExpression.
This seems to always work correctly from JSF, whether deferred evaluation is
used for the value or not. But this was only tested with the output
mechanism in login.xhtml so it may just be good/bad luck.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-398) DelegateHandler cached too agressively
DelegateHandler cached too agressively -- Key: OWB-398 URL: https://issues.apache.org/jira/browse/OWB-398 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener The InterceptorHandler and OpenWebbeansEJBinterceptor keep the interceptor that hooks the decorator stack in the cached interceptor stack. This can lead to an incorrect delegate handler being used, and in the case of an decorated EJB can cause the wrong EJB InvocationContext to be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-398) DelegateHandler cached too agressively
[ https://issues.apache.org/jira/browse/OWB-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-398. -- Fix Version/s: 1.0.0-CR1 Resolution: Fixed http://svn.apache.org/viewvc?rev=955801view=rev (tagged with wrong JIRA id) DelegateHandler cached too agressively -- Key: OWB-398 URL: https://issues.apache.org/jira/browse/OWB-398 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0-CR1 Original Estimate: 8h Remaining Estimate: 8h The InterceptorHandler and OpenWebbeansEJBinterceptor keep the interceptor that hooks the decorator stack in the cached interceptor stack. This can lead to an incorrect delegate handler being used, and in the case of an decorated EJB can cause the wrong EJB InvocationContext to be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-378) ejb at bottom of decorator stack doesn't handle changed method
[ https://issues.apache.org/jira/browse/OWB-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-378. -- Resolution: Fixed ejb at bottom of decorator stack doesn't handle changed method -- Key: OWB-378 URL: https://issues.apache.org/jira/browse/OWB-378 Project: OpenWebBeans Issue Type: Bug Components: Java EE Integration Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Original Estimate: 4h Remaining Estimate: 4h if a decorator changes the method call, we still call the original ejbcontext.proceed() when we hit the end of the line for decorators. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-371) no lifecycle interceptors for non-contextual EJB
no lifecycle interceptors for non-contextual EJB Key: OWB-371 URL: https://issues.apache.org/jira/browse/OWB-371 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Gurkan Erdogdu The current OpenWebBeansEjbInterceptor only does work in its postConstruct/preDestroy when the EJB was contextual. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-371) no lifecycle interceptors for non-contextual EJB
[ https://issues.apache.org/jira/browse/OWB-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867298#action_12867298 ] Eric Covener commented on OWB-371: -- I wasn't sure about the proper behavior, but 7.2 says: Invocation of lifecycle callbacks by the container are not business method invocations, but are intercepted by interceptors for lifecycle callbacks. no lifecycle interceptors for non-contextual EJB Key: OWB-371 URL: https://issues.apache.org/jira/browse/OWB-371 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Gurkan Erdogdu Original Estimate: 4h Remaining Estimate: 4h The current OpenWebBeansEjbInterceptor only does work in its postConstruct/preDestroy when the EJB was contextual. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-372) creational context not cleaned up for non-contextual EJB interceptions
creational context not cleaned up for non-contextual EJB interceptions -- Key: OWB-372 URL: https://issues.apache.org/jira/browse/OWB-372 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Gurkan Erdogdu we create a null CC in the OWBEJB interceptor, but it's never stashed away to be cleaned up during e.g. preDestroy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-365) make injection optional in OWBEJBInterceptor
make injection optional in OWBEJBInterceptor Key: OWB-365 URL: https://issues.apache.org/jira/browse/OWB-365 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup, Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0 the injection portion of the @PostConstruct callback in the OWBEJBInterceptor should be suppressable via a openwebbeans property, in case the container is performing 299 injection of EJB's via existing EE injection mechaniss -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-361) underlying EJB method not actually in our interceptors stack
underlying EJB method not actually in our interceptors stack Key: OWB-361 URL: https://issues.apache.org/jira/browse/OWB-361 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor When the OWBEjbInterceptor is hooked into an EJB interceptor stack, and the final 299 interceptor calls context.proceed(), they don't see the return value of the underlying EJB method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-357) WebbeansFinder should index first on ClassLoader, not singleton type
WebbeansFinder should index first on ClassLoader, not singleton type Key: OWB-357 URL: https://issues.apache.org/jira/browse/OWB-357 Project: OpenWebBeans Issue Type: Bug Affects Versions: M4 Environment: tiered classloader Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: M4 I'm finding WebbeansFinder a little difficult to work with since it is unable to easily clear all instances a / the current classloader. I would like to change the map to have the primary index on the classloader from: private static MapString, MapClassLoader, Object singletonMap = new HashMapString, MapClassLoader, Object(); to private static MapClassLoader, MapString, Object singletonMap = new HashMapClassLoader, MapString, Object(); Currently, this only really breaks removeInstance(String name) which AFAICT has no callers. This would be replaced by e.g. clearInstance(ClassLoader cl) And most current callers of clearInstances() would I think prefer to just clear an individual classloader. Opinions welcome, and curious if anyone wants to preserve a removeInstance(String name) method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OWB-318) multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances
[ https://issues.apache.org/jira/browse/OWB-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-318. -- Resolution: Fixed duplicate @Interceptors in a managed bean now share an instance of the interceptor class multiple methods with same EJB @interceptors(foo.class) in same bean class get multiple interceptor instances - Key: OWB-318 URL: https://issues.apache.org/jira/browse/OWB-318 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Original Estimate: 6h Remaining Estimate: 6h One managed bean with multiple methods with the same EJB @interceptors(foo.class) get multiple interceptor instances, but we should only create 1 instance. See TCK method org.jboss.jsr299.tck.interceptors.tests.method.MethodLevelInterceptorTest.testInterceptorCanBeAppliedToMoreThanOneMethod(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-311) @ExcludeClassInterceptors doesn't remove in all cases
@ExcludeClassInterceptors doesn't remove in all cases - Key: OWB-311 URL: https://issues.apache.org/jira/browse/OWB-311 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: M4 Conditions in @ExcludeClassInterceptors seems unnecessarily complicated, and doesn't properly remove class-level interceptors on methods with @ExcludeCLassInterceptros and no other method-level @Interceptors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-311) @ExcludeClassInterceptors doesn't remove in all cases
[ https://issues.apache.org/jira/browse/OWB-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-311. -- Resolution: Fixed @ExcludeClassInterceptors doesn't remove in all cases - Key: OWB-311 URL: https://issues.apache.org/jira/browse/OWB-311 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: M4 Original Estimate: 1h Remaining Estimate: 1h Conditions in @ExcludeClassInterceptors seems unnecessarily complicated, and doesn't properly remove class-level interceptors on methods with @ExcludeCLassInterceptros and no other method-level @Interceptors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-306) overrridden @AroundInvoke and lifecycle interceptors are still run
overrridden @AroundInvoke and lifecycle interceptors are still run -- Key: OWB-306 URL: https://issues.apache.org/jira/browse/OWB-306 Project: OpenWebBeans Issue Type: Bug Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Interceptor spec says: --- If an around-invoke method is overridden by another method (regardless of whether that method is itself an around-invoke method), it will not be invoked. If a lifecycle callback interceptor method is overridden by another method (regardless of whether that method is itself a lifecycle callback interceptor method (of the same or different type)), it will not be invoked. --- I don't have a fix for this issue, but it is at least conceptually pretty easy to grok. It seems that we can't just check the stack or even all enabled interceptors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-307) InvocationContext.setParameters() and primitive vs. wrapped types
InvocationContext.setParameters() and primitive vs. wrapped types - Key: OWB-307 URL: https://issues.apache.org/jira/browse/OWB-307 Project: OpenWebBeans Issue Type: Bug Affects Versions: M3 Reporter: Eric Covener Assignee: Gurkan Erdogdu Fix For: 1.0.0 right now setParameters() on a method with primtiive types does not permit the wrapped types to be set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-309) signature check for @Interceptors-enabled interceptors is too strict
signature check for @Interceptors-enabled interceptors is too strict Key: OWB-309 URL: https://issues.apache.org/jira/browse/OWB-309 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: M4 Sometimes having the wrong kind of signature (defined in bean class vs. defined in an interceptor) just means the method is n/a to the current bean we're looking at. Don't throw an exception for an unexpected InvocationContext, just don't enable the method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-271) method-level interceptor bindings not inherited properly
[ https://issues.apache.org/jira/browse/OWB-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-271. -- Resolution: Fixed Fix Version/s: (was: 1.0.0) M4 method-level interceptor bindings not inherited properly Key: OWB-271 URL: https://issues.apache.org/jira/browse/OWB-271 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: M4 Original Estimate: 4h Remaining Estimate: 4h If a subclass doesn't implement a method of an ancestor, and that ancestor has interceptor bindings, WebBeansInterceptorConfig will fail to consider those bindings when it builds the list of valid interceptors. The main culprit here is only getting declared methods, as opposed to all methods, of the bean class. Also, the routine that configured component-level interceptors already knows the full set of component-level bindings (already has resolved all the transitive and inheritance stuff) so this should be passed explicitly to the routine that determines the method-level interceptors (instead of trying to derive it again). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-266) transitive interceptor bindings not applied to Bean subclasses
[ https://issues.apache.org/jira/browse/OWB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-266. -- Resolution: Fixed Fix Version/s: (was: 1.0.0) M4 transitive interceptor bindings not applied to Bean subclasses -- Key: OWB-266 URL: https://issues.apache.org/jira/browse/OWB-266 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: M4 Attachments: transitive_subclass.diff Original Estimate: 4h Remaining Estimate: 4h For @Inherited InterceptorBinding A that has transitive bindings X,Y declared: X and Y intercept a class annotated with @A, but not a subclass of @A. We are missing logic like existing hasInterceptorBindingMetaAnnotation() on the result of querying the inherited metadata. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-266) transitive interceptor bindings not applied to Bean subclasses
transitive interceptor bindings not applied to Bean subclasses -- Key: OWB-266 URL: https://issues.apache.org/jira/browse/OWB-266 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Attachments: transitive_subclass.diff For @Inherited InterceptorBinding A that has transitive bindings X,Y declared: X and Y intercept a class annotated with @A, but not a subclass of @A. We are missing logic like existing hasInterceptorBindingMetaAnnotation() on the result of querying the inherited metadata. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-266) transitive interceptor bindings not applied to Bean subclasses
[ https://issues.apache.org/jira/browse/OWB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829886#action_12829886 ] Eric Covener commented on OWB-266: -- eek, X and Y intercept a class annotated with @A, but not a subclass of @A. Should read X and Y intercept a class annotated with @A, but not a subclass of _the bean annotated with_ @A. transitive interceptor bindings not applied to Bean subclasses -- Key: OWB-266 URL: https://issues.apache.org/jira/browse/OWB-266 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Fix For: 1.0.0 Attachments: transitive_subclass.diff Original Estimate: 4h Remaining Estimate: 4h For @Inherited InterceptorBinding A that has transitive bindings X,Y declared: X and Y intercept a class annotated with @A, but not a subclass of @A. We are missing logic like existing hasInterceptorBindingMetaAnnotation() on the result of querying the inherited metadata. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-255) injection point errors at deployment don't tell you the injection point!
injection point errors at deployment don't tell you the injection point! Key: OWB-255 URL: https://issues.apache.org/jira/browse/OWB-255 Project: OpenWebBeans Issue Type: Improvement Components: Injection and Lookup Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Priority: Trivial If you have an unsatisfiable or ambiguous injection detected during ResolutionUtil.checkResolvedBeans(), the exception thrown doesn't tell you what class has the problematic injection point. For the easiest of these exceptions to hit, we could have passed on the InjectionPoint and gotten to e.g. the bean class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-232) exceptions with non-OWB XML don't contain interceptor/decorator classnames
[ https://issues.apache.org/jira/browse/OWB-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-232. -- Resolution: Fixed exceptions with non-OWB XML don't contain interceptor/decorator classnames -- Key: OWB-232 URL: https://issues.apache.org/jira/browse/OWB-232 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: M3 Reporter: Eric Covener Assignee: Eric Covener Priority: Trivial Fix For: M4 Original Estimate: 0.5h Remaining Estimate: 0.5h The exceptions for non-OWB-specific XML just say that class is not found or a duplicate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
