Re: OWB 2 not firing ProcessAnnotatedType for all bean classes

[Eric Covener]

On Sun, Jul 23, 2017 at 8:13 AM, John D. Ament  wrote:
> We should probably review on cdi-dev.  I believe the intention behind
> saying "classes discovered"  [1] is to indicate that its for all classes,
> not just eligible beans.  Here's a use case: I have framework specific
> classes, where the developer isn't required to add a scope.  Framework adds
> the scope for them.  To do that, they use bean-discovery-mode=annotated and
> PAT will add the dependent or other scope as appropriate.
>
> [1]:
> https://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#process_annotated_type
>
> On Sat, Jul 22, 2017 at 5:40 PM Mark Struberg 
> wrote:
>
>> In that case Romain is right.
>>
>> In an implicit BDA you only get PAT if the class has a bean defining
>> annotation.
>> Thats the reason we introduced all+trim.


John alluded to changing, not adding, a beans.xml in the OP, so IIUC
if it did not contain bean-discovery-mode=all + trim  then it seems to
me that the type should have been processed.

Re: rename owb-2.0 to owb-1.5?

[Eric Covener]

On Sat, Aug 30, 2014 at 3:01 AM, Mark Struberg strub...@yahoo.de wrote:
 What about renaming our current trunk to 1.5.0-SNAPSHOT?

+1, awfully confusing w/o it.

-- 
Eric Covener
cove...@gmail.com

Re: BDA scanning via isBDABeansXmlScanningEnabled

[Eric Covener]

On Sun, May 11, 2014 at 4:55 PM, Mark Struberg strub...@yahoo.de wrote:
 The current impl of isBDABeansXmlScanningEnabled() is pretty much 
 disfunctional.
 This has to do that the BDA specification in CDI-1.1 is not as clear as it 
 should be.

+1.  IMO even if 1.1 is still unclear, it stil seems to have distanced
itself from isBDABeansXmlScanningEnabled() style BDA relative to 1.0.

Re: [VOTE] Release Apache OpenWebBeans-1.2.2

[Eric Covener]

err once more with dev@

On Thu, Feb 20, 2014 at 11:19 AM, Eric Covener cove...@gmail.com wrote:
 Source Release:
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1001/org/apache/openwebbeans/openwebbeans/1.2.2/openwebbeans-1.2.2-source-release.zip

 +1



-- 
Eric Covener
cove...@gmail.com

Re: targetting CDI-1.1 in trunk

[Eric Covener]

 I suggest we move the current trunk to an owb_1.2.x branch and move our
 trunk to target the new CDI-1.1 MR release (as discussed in November
 already).
 Then I'll go on and cut an owb-1.2.2 release from the branch.

+1

[jira] [Commented] (OWB-771) Invocation​ContextImpl cleans target field if occurs an exception

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

[ 
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

[jira] [Commented] (OWB-738) CODI @ConversationScope + @Stateful in a bean = java.lang.StackOverflowError

[Eric Covener (JIRA)]

[ 
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 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanInstance

Re: [VOTE] release Apache OpenWebBeans 1.1.5

[Eric Covener]

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-126/org/apache/openwebbeans/openwebbeans/1.1.5/openwebbeans-1.1.5-source-release.zip

+1

Re: [VOTE] take2 Release Apache OpenWebBeans-1.1.4

[Eric Covener]

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.4/

 Source release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/org/apache/openwebbeans/openwebbeans/1.1.4/openwebbeans-1.1.4-source-release.zip

+1

Re: OWB Decorators

[Eric Covener]

 Is this a bug or is it not allowed to call other methods than the decorated 
 one
 in the decorator method?

I think the behavior he expects is the correct behavior, having not
looked at the code, as the stack unwinds we need to back up the
decorator we're looking at as next.

Re: [DISCUSS] remove webbeans-openejb module from OWB

[Eric Covener]

   Thus I'd like to remove the webbeans-openejb module from OWB.

+1 on any branch other than 1.0.

[jira] [Commented] (OWB-655) CDI doesn´t inject stateless EJB by abstract class.

[Eric Covener (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234813#comment-13234813
 ] 

Eric Covener commented on OWB-655:
--

Does it really require the base class to be abstract, IOW when the no-interface 
view is being used do other non-abstract super classes work for injection?

 CDI doesn´t inject stateless EJB by abstract class.
 ---

 Key: OWB-655
 URL: https://issues.apache.org/jira/browse/OWB-655
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Enterprise Web Beans
Affects Versions: 1.1.3
Reporter: Rogerio Baldini
Assignee: Gurkan Erdogdu

 I have these classes:
 public abstract class PlcBaseDAO {}
 public abstract class PlcBaseJpaDAO extends PlcBaseDAO  {}
 @Stateless
 public class AppJpaDAO extends PlcBaseJpaDAO {}
 And this injection doesn´t work.
 @Named
 public class AppCDI {
   @Inject
   private PlcBaseDAO baseDao;
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-655) CDI doesn´t inject stateless EJB by abstract class.

[Eric Covener (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234928#comment-13234928
 ] 

Eric Covener commented on OWB-655:
--

We wouldn't inject an abstract class, we'd include the abstract class in the 
list of bean types of the EJB with a no-interface view. 

When someone requested a java type with that abstract class, and this was the 
only bean with that type, we'd find our way to this enterprise bean ask the 
container for an EJB and inject [a proxy to] that.

 CDI doesn´t inject stateless EJB by abstract class.
 ---

 Key: OWB-655
 URL: https://issues.apache.org/jira/browse/OWB-655
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Enterprise Web Beans
Affects Versions: 1.1.3
Reporter: Rogerio Baldini
Assignee: Gurkan Erdogdu

 I have these classes:
 public abstract class PlcBaseDAO {}
 public abstract class PlcBaseJpaDAO extends PlcBaseDAO  {}
 @Stateless
 public class AppJpaDAO extends PlcBaseJpaDAO {}
 And this injection doesn´t work.
 @Named
 public class AppCDI {
   @Inject
   private PlcBaseDAO baseDao;
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-649) exceptions in EJB's are wrapped in InvocationTargetException

[Eric Covener (Created) (JIRA)]

exceptions in EJB's are wrapped in InvocationTargetException


 Key: OWB-649
 URL: https://issues.apache.org/jira/browse/OWB-649
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Enterprise Web Beans
Affects Versions: 1.1.3
Reporter: Eric Covener
Assignee: Eric Covener
 Fix For: 1.1.4


When an EJB is @Injected and the EjbBeanproxyHandler is used as the javassist 
MethodHandler, exceptions become wrapped in InvocationTargetException which a 
caller might not be prepared to inspect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-649) exceptions in EJB's are wrapped in InvocationTargetException

[Eric Covener (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Covener resolved OWB-649.
--

Resolution: Fixed

 exceptions in EJB's are wrapped in InvocationTargetException
 

 Key: OWB-649
 URL: https://issues.apache.org/jira/browse/OWB-649
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Enterprise Web Beans
Affects Versions: 1.1.3
Reporter: Eric Covener
Assignee: Eric Covener
 Fix For: 1.1.4

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 When an EJB is @Injected and the EjbBeanproxyHandler is used as the javassist 
 MethodHandler, exceptions become wrapped in InvocationTargetException which a 
 caller might not be prepared to inspect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Apache OpenWebBeans-1.1.2

[Eric Covener]

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-072/org/apache/openwebbeans/openwebbeans/1.1.2/openwebbeans-1.1.2-source-release.zip

+1 for GA

Re: svn commit: r1079926 - /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java

[Eric Covener]

I'm looking at an issue and have a question about this area of the
code. I'm working with a dependent bean that has interceptors, so it
is proxied.

It seems to me like the final argument of
CreationalContextImpl#addDependent() is meant to be a contextual
instance -- something suitable to be returned from Contextual.create()
or Contextual.destroy().   The same things that should only ever
directly be pulled from a Context.

In this case though, it seems like at injection time we're passing not
a contextual instance, but a  contextual reference (e.g. our own
javassist proxy) like we'd inject or provide via a call to
BeanManager.getReference().

This will cause us to later call Contextual.destroy() on a
proxy/reference instead of a contextual instance itself.  Does the
adding of dependents need to be pushed down into places where
Contextual.create() is really called?

Can anyone shed some light on this?


On Wed, Mar 9, 2011 at 1:44 PM,  strub...@apache.org wrote:
 Author: struberg
 Date: Wed Mar  9 18:44:04 2011
 New Revision: 1079926

 URL: http://svn.apache.org/viewvc?rev=1079926view=rev
 Log:
 OWB-542 oops, something went wrong with the revert. all fixed now ;)

 Modified:
    
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java

 Modified: 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java
 URL: 
 http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java?rev=1079926r1=1079925r2=1079926view=diff
 ==
 --- 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java
  (original)
 +++ 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/AbstractInjectable.java
  Wed Mar  9 18:44:04 2011
 @@ -37,6 +37,7 @@ import org.apache.webbeans.component.Inj
  import org.apache.webbeans.component.InstanceBean;
  import org.apache.webbeans.component.OwbBean;
  import org.apache.webbeans.container.InjectionResolver;
 +import org.apache.webbeans.context.creational.CreationalContextImpl;
  import org.apache.webbeans.context.creational.DependentCreationalContext;
  import org.apache.webbeans.util.ClassUtil;
  import org.apache.webbeans.util.WebBeansUtil;
 @@ -138,6 +139,15 @@ public abstract class AbstractInjectable
             }
         }

 +        // add this dependent into bean dependent list
 +        if (!WebBeansUtil.isStaticInjection(injectionPoint)  
 WebBeansUtil.isDependent(injectedBean))
 +        {
 +            if(instanceUnderInjection.get() != null)
 +            {
 +                
 ((CreationalContextImpl?)this.injectionOwnerCreationalContext).addDependent(instanceUnderInjection.get(),injectedBean,
  injected);
 +            }
 +        }
 +
         return injected;
     }







-- 
Eric Covener
cove...@gmail.com

Re: [VOTE] release Apache OpenWebBeans 1.1.0

[Eric Covener]

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-040/org/apache/openwebbeans/openwebbeans/1.1.0/openwebbeans-1.1.0-source-release.zip

+1 (sigs, checksums, built and did reasonably well on standalone TCK)

[jira] [Updated] (OWB-479) detect loops in producer beans vs. producer method parameters at deployment time

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

Re: [jira] Commented: (OWB-472) archive centric beans.xml enabling

[Eric Covener]

On Sun, Feb 13, 2011 at 4:12 PM, Gerhard gerhard.petra...@gmail.com wrote:
 yes - it's non-intrusive because i fixed it.

Non-intrusive in terms of technical rationale to call for a revert,
not non-intrusive in terms of you had to refactor to use trunk in an
appserver.

 however, we have a spi (ScannerService) for such additional features.

We have many SPIs and Plugins, and in trunk we have a set that can
satisfy the requirements of CDI 1.0.

Re: Yan:: svn commit: r1042754 - /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml

[Eric Covener]

On Wed, Dec 8, 2010 at 1:25 PM, David Jencks david_jen...@yahoo.com wrote:
 Investigating this is taking longer than I hoped.  There's a tck test for 
 6.4.3, but it doesn't test most of the requirements in 6.4.3 and it's not 
 clear to me that it has any relevance to how EL would work in a jsp or jsf 
 page since the test doesn't involve a jsp or jsf.  I enhanced the test to 
 check the destroy at end of evaluation and new expression results in new 
 bean requirements and now it fails in geronimo with or without the 
 modification in faces-config.xml because the beans aren't getting destroyed 
 after expression evaluation.  I'm going to try writing an actual jsp page to 
 check if it works.


FYI I'm not sure OWB-401 is actually resolved.

[jira] Created: (OWB-488) move WebBeansConfigurationException messages to message bundles

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

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.

Re: [VOTE] release Apache OpenWebBeans-1.0.0 2nd try

[Eric Covener]

 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto 
 (and reason why)
+1

Re: [ANN] Welcome Paul J Reder as new committer!

[Eric Covener]

On Fri, Oct 8, 2010 at 12:41 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 The Apache OpenWebBeans PMC is pleased to announce  that Paul J Reder has 
 accepted
 our invitation to join OWB as a committer.

Congrats Paul!

-- 
Eric Covener
cove...@gmail.com

Re: [ANN] Welcome Rohit Kelapure as new committer!

[Eric Covener]

On Wed, Oct 6, 2010 at 2:48 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 All,

 The OpenWebBeans PMC is pleased to announce  that Rohit Kelapure has accepted
 our invitation to join OWB as committer.


Congrats Rohit!

Re: last TCK run

[Eric Covener]

On Thu, Sep 30, 2010 at 8:57 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi!

 Before doing a release this afternoon, I'm currently running the TCK again.

 For standalone, I have one test which fails:
 DestroyedInstanceReturnedByGetTest

 Anyone knows anything about it?


That's one of three I am used to seeing in my sandbox.

Re: last TCK run

[Eric Covener]

On Thu, Sep 30, 2010 at 9:20 AM, Mark Struberg strub...@yahoo.de wrote:
 and the others?


Failed tests:
  
testDestroyedInstanceMustNotBeReturnedByGet(org.jboss.jsr299.tck.tests.context.DestroyedInstanceReturnedByGetTest)
  
testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest)
  
testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest)

Tests run: 574, Failures: 3, Errors: 0, Skipped: 0

[jira] Resolved: (OWB-465) enhance EJB common code for crude @LocalBean support

[Eric Covener (JIRA)]

 [ 
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.

Re: ambiguous dependencies when using multiple qualifiers

[Eric Covener]

 I also took a look in the CDI spec about this, but could only find the
 following from section 2.3.4: A bean may only be injected to an
 injection point if it has all the qualifiers of the injection point.
 Of course this applies to both producers and thus, yes, it's kinda
 ambiguous.

When an ambiguous dependency exists, the container attempts to
resolve the ambiguity. The container eliminates all eligible beans
that are not alternatives, except for producer methods and fields of
beans that are alternatives. If there is exactly one bean remaining,
the container will select this bean, and the ambiguous dependency is
called resolvable.

The spec says both producers satisfy the injection point, and does not
allow it to discard the one with additional qualifiers.

-- 
Eric Covener
cove...@gmail.com

Re: [cwiki] owb-committers

[Eric Covener]

On Tue, Sep 28, 2010 at 9:07 AM, Gerhard gerhard.petra...@gmail.com wrote:
 @committers:
 please post your confluence user-names and i'll add them to the
 committers-group.


Thanks for this -- I just registered with cove...@apache.org as username.

Re: [DISCUSS] releasing owb-1.0.0-alpha-3

[Eric Covener]

On Tue, Sep 28, 2010 at 4:22 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 We had a few very important changes in the last few weeks

 *) mem leak fix
 *) upgrade to a few newer lib versions
 *) lazy SessionContext creation
 *) site fix (currently in progress locally)
 *) PrePassivate, PostActivate, and AroundTimeout support
 *) lots of EJB improvements

 I'd like to run the release tasks for 1.0.0-alpha-3 tomorrow, WDYT?
 If you like to complete/test some feature which you think must go into this 
 release, then please ping me.

Before 1.0, should we update the name of the openwebbeans/
subdirectories and/or the maven output jars for ejb/openejb?

webbeans-ejb produces webbeans-ejb-common.jar (which does not depend on openejb)
webbeans-openejb produces webbeans-ejb.jar (which depends on openejb)

Just my pet peeve/confusion, if they were just ejb-common/ejb-common
and ejb-openejb/ejb-openejb (or openejb/openejb) it would be less
confusing.

Of course I have no idea of the conventions in this area, the
packaging ramifications, or am able to actually do the work :)

-- 
Eric Covener
cove...@gmail.com

[jira] Resolved: (OWB-463) EjbDefinitionUtility.defineEjbBeanProxy() should be able to create proxies for no-interface local beans

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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'

[Eric Covener (JIRA)]

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'

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

[ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

[ 
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.

Re: [VOTE] release Apache OpenWebBeans-1.0.0-alpha-2

[Eric Covener]

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-158/org/apache/openwebbeans/openwebbeans/1.0.0-alpha-2/openwebbeans-1.0.0-alpha-2-source-release.zip

+1 for alpha, tested ejb-sample in tomcat+openejb

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r932843 - in /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common: component/BaseEjbBean.java interceptor/OpenWebBeansEjbInterceptor.java proxy/EjbBeanProxyHan

[Eric Covener]

Finally, does this work whether or not the EJB itself was contextual?
 This is written to work with contextual EJB beans. If the EJB bean is not 
 contextual, then it does not support decorators but supports JSR299 style
 interceptors. We could create a new EJB interceptor/utility for returning 
 interceptors for non-contextual ejbs.

Gurkan,

Revisiting this old thread -- are you sure the non-contextual case
should not be deocratable? I think this became part of my conventional
wisdom but I can't find any basis for it.

It seems decoration sould be easy  to add to our interceptor for
non-contextual -- in fact I think all the contextual vs non-contextual
distinction can go away if we do a little more work in @PostConstruct.

(hope to look at it this week)

-- 
Eric Covener
cove...@gmail.com

lifecycle interceptors for EJBs

[Eric Covener]

In our OWBEjbInterceptor, we have a disconnect between how
@AroundInvoke and @PostConstruct/@PreDestroy are handled.

In the former, we only call the ejb containers ic.proceed() when we
fall off the end of our own ic.proceed() -- this seems good because it
means the last 299 interceptor called proceed, allowing the biz method
to run.

But for the lifecycle (PostConstruct, PreDestroy) callbacks, we call
the ejb containers ic.proceed() no matter what the 299 interceptors
did (e.g. did not call through 299 ic.proceed to the bottom) -- in the
OpenWebBeansEJBInterceptor itself.  Shouldn't this behave like
@AroundInvoke and only call the EJB one when we fall off the bottom of
our own invocation context?

-- 
Eric Covener
cove...@gmail.com

Re: lifecycle interceptors for EJBs

[Eric Covener]

On Wed, Aug 25, 2010 at 2:24 PM, Eric Covener cove...@gmail.com wrote:
 In our OWBEjbInterceptor, we have a disconnect between how
 @AroundInvoke and @PostConstruct/@PreDestroy are handled.

answered offline -- aroundinvoke is right and lifecycles should
ultimately behave the same.

-- 
Eric Covener
cove...@gmail.com

Re: EJB Bean Stateful Bean Remove Methods

[Eric Covener]

On Thu, Aug 19, 2010 at 3:05 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Hi;

 I am trying to understand the current implementation in our 
 EjbBeanProxyHandler
 and BaseEJBBeans.


 If I understand correctly,

 1*) BaseEjbBeans hold map : proxy -- dependent EJB stateful instance
 2*) When a call is made to remove method of the stateful instance and bean is
 dependent scope,  then remove dependent EJB stateful instance from 
 BaseEJBBean
 map and do nothing

We do not stop the direct invocation here -- we note it and allow the
call to flow through.

 3*) When the bean is destroyed and if it is dependent, then call Remove method
 of the stateful instance over container. But if the stateful is removed from 
 map
 via item-2, then no remove method invocation occurs.


 But spec. says that
 1*) If the bean is dependent scope and remove method is called, Call ejb 
 remove
 method with EMPTY parameters (this is only occured in our case with item-3 
 i.e,
 but destruction of ejb instance is delayed to destroy phase, I think this is 
 not
 correct. We have to call remove method of the EJB at the time call is made)

I don't understand this requirement in practice -- currently we do let
the remove method be called when it's invoked in the
EJBBeanProxyHandler, then we stop tracking it.

Should we really step between the caller and the container and somehow
remove parameters?

 2*) When the bean is destroyed, if the bean is dependent and removed already 
 via
 1, do nothing else container internally removes the bean instance. (In our
 case, we do nothing on non-dependent scopes, I think this is not correct, we
 also have to call internal remove method of the container)


Yes this one looks busted, for normal scopes we should be causing the
instance to be removed by the container unconditionally in
Contextual.destroy(), since we always blocked the user from calling
it.

In a destroy() method is is still possible to check the context to
make sure we actually obtained an EJB?

-- 
Eric Covener
cove...@gmail.com

[jira] Resolved: (OWB-442) our EJB proxies are broken when multiple local interfaces are used on a single class

[Eric Covener (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Covener resolved OWB-442.
--

Fix Version/s: 1.0.0-alpha-2
   Resolution: Fixed

 our EJB proxies are broken when multiple local interfaces are used on a 
 single class
 

 Key: OWB-442
 URL: https://issues.apache.org/jira/browse/OWB-442
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration
Affects Versions: 1.0.0-alpha-1
Reporter: Eric Covener
Assignee: Eric Covener
 Fix For: 1.0.0-alpha-2

   Original Estimate: 2h
  Remaining Estimate: 2h

 our javassist proxies for EJB beans only implement the single injected type, 
 but they are stored in a cache keyed solely off the managed bean class.  
 We need either another dimension for the type, or to set all local interfaces 
 on the proxy.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: EJB Bean Stateful Bean Remove Methods

[Eric Covener]

In a destroy() method is is still possible to check the context to
make  sure we actually obtained an EJB?
 We have to get an EJB instance under proxy to call remove method. What is you
 concern here?

My concern was to make sure we didn't cause one to be created just to
remove it -- in such a case where the method invocation handler was
never invoked and never actually obtained an EJB.

I think all is well though.

-- 
Eric Covener
cove...@gmail.com

[jira] Resolved: (OWB-443) Normal-scoped EJB not removed by container during Contextual.destroy()

[Eric Covener (JIRA)]

 [ 
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.

jboss-test-harness.properties in both -tck and -porting?

[Eric Covener]

Why do we have two copies of jboss-test-harness.properties, one in
-tck and one in -porting?   Should they always have the same contents?

It seems like the harness blows up if these are out of synch.

-- 
Eric Covener
cove...@gmail.com

[jira] Created: (OWB-442) our EJB proxies are broken when multiple local interfaces are used on a single class

[Eric Covener (JIRA)]

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.

Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/

[Eric Covener]

On Mon, Aug 16, 2010 at 2:06 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
This proxy internally uses EJB
proxy instance that implements all of  local interfaces.
 This may be internally handled by the OpenEJB.

 Look org.apache.openejb.core.ivm.EjbHomeProxyHandler class in
 container/openejb-core project.

FYI I've confirmed that the container I'm working with really needs
the local interface when there's more than 1 local interface on the
EJB class, so I will try to introduce a safe mechanism to pass the
injected iface down.

Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/

[Eric Covener]

On Mon, Aug 16, 2010 at 11:20 AM, Eric Covener cove...@gmail.com wrote:
 On Mon, Aug 16, 2010 at 2:06 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com 
 wrote:
This proxy internally uses EJB
proxy instance that implements all of  local interfaces.
 This may be internally handled by the OpenEJB.

 Look org.apache.openejb.core.ivm.EjbHomeProxyHandler class in
 container/openejb-core project.

 FYI I've confirmed that the container I'm working with really needs
 the local interface when there's more than 1 local interface on the
 EJB class, so I will try to introduce a safe mechanism to pass the
 injected iface down.


Realizing now that this is a bigger problem in actually retrieving the
ejb instances from the context -- they're not interchangeable in the
case that the container does not return EJBs capable of all local
interfaces.

-- 
Eric Covener
cove...@gmail.com

Re: ELContextStore Question

[Eric Covener]

slightly off-topic, but Mark I was wondering if you could explain why
we need to call destroyELContextStore from both the
WebBeansConfigurationListener and from the end of the RequestContext?
Is there some path that would only hit one of these callers?

[jira] Commented: (OWB-435) What is the expected result for following 2 decorators?

[Eric Covener (JIRA)]

[ 
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.

Re: [DISCUSS] releasing owb-1.0.0 next week?

[Eric Covener]

On Tue, Aug 10, 2010 at 3:37 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 Gurkan and I had a small chat yesterday about the stability of OpenWebBeans. 
 And
 we both agree that it really would deserve a 1.0.0 number because it's pretty
 stable. At least a lot more stable than many commercial products with a 1.0
 release number ;)

+1, I hope to work on BDA awareness in the scanner service /
{Bean,Alternatives,Interceptor}Manager stuff and I don't want to
derail 1.0 with it!

Would we branch at 1.0, and would 1.0 still be CTR?


-- 
Eric Covener
cove...@gmail.com

299 q: AfterBeanDiscovery.addBean()

[Eric Covener]

In 299, If a portable extension used AfterBeanDiscovery.addBean() to
add a managed bean to an application:

1) If that bean was already in a BDA we knew about, why bother adding
it this way?
2) If that bean was not already in a BDA, is it now uninterceptable
and undecoratable because there's no ways to enable anything for it?
I couldn't find an alternative mechanism for enablement.

-- 
Eric Covener
cove...@gmail.com

[jira] Commented: (OWB-431) Generic Type Inheritance not resolved correctly

[Eric Covener (JIRA)]

[ 
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

Re: is usage of BaseEjbBean.iface safe?

[Eric Covener]

On Wed, Jul 28, 2010 at 1:40 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
Good catch Eric!
 Not mean that current logic is wrong.

 Bean API types are  local interfaces of the EJB bean  . We check all injection
 fields at deployment time for validation. If there is no validation error, 
 using
 of EJB local interfaces are correct.


 What is the problem that you think about?

My concern is that at runtime, each time we perform injection various
threads are poking around at BaseEjbBean.iface when really all they
need to is use the iface on the stack to create their
proxies/instances.  This is because there is not actually one iface
per BaseEjbBean (EJB class), just one per injection point.

-- 
Eric Covener
cove...@gmail.com

Re: is usage of BaseEjbBean.iface safe?

[Eric Covener]

On Wed, Jul 28, 2010 at 7:55 AM, Eric Covener cove...@gmail.com wrote:
 On Wed, Jul 28, 2010 at 1:40 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com 
 wrote:
Good catch Eric!
 Not mean that current logic is wrong.

 Bean API types are  local interfaces of the EJB bean  . We check all 
 injection
 fields at deployment time for validation. If there is no validation error, 
 using
 of EJB local interfaces are correct.


 What is the problem that you think about?

 My concern is that at runtime, each time we perform injection various
 threads are poking around at BaseEjbBean.iface when really all they
 need to is use the iface on the stack to create their
 proxies/instances.  This is because there is not actually one iface
 per BaseEjbBean (EJB class), just one per injection point.


Although now I'm not sure if we can properly know the injected iface
when it's time to get the instance, since we are funneled through the
Contextual.getInstance() interface.

But stashing away the injected iface in the BaseEjbBean in between
proxy creation and obtaining the instance does not seem threadsafe.

-- 
Eric Covener
cove...@gmail.com

is usage of BaseEjbBean.iface safe?

[Eric Covener]

If we have 1 EJB bean class, we only have 1 ENTERPRISE managed bean
and one BaseEjbBean.iface.

But if this EJB has two or more local interfaces, it can be injected
as under multiple interfaces.  It seems like the interface should only
be passsed around on the stack not actually associated with the
enterprise bean itself.

Does this sound right?

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r979071 - in /openwebbeans/trunk: webbeans-ejb/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/interceptor/ webbeans-impl/ webbeans-impl/src/main/java/org/apache/webbeans/

[Eric Covener]

On Mon, Jul 26, 2010 at 10:10 AM, Gurkan Erdogdu
gurkanerdo...@yahoo.com wrote:
 Hello,

 This commit breaks following TCK tests,

 1- DecoratorAndInterceptorTest # testInterceptorCalledBeforeDecorator
 2- InterceptorCalledBeforeDecoratorTest # testInterceptorCalledBeforeDecorator


I may be reverting this due to the EJB dependency leaking into -impl,
will take a look this afternoon.  I ran standalone with no
regression, but must have done something wrong.

-- 
Eric Covener
cove...@gmail.com

Re: CIA bot on #openwebbeans?

[Eric Covener]

On Sun, Jul 25, 2010 at 4:45 PM, Rohit Kelapure kelap...@gmail.com wrote:
 +1

 On Sun, Jul 25, 2010 at 1:28 PM, Eric Covener cove...@gmail.com wrote:
 How do people feel / who do we ask to turn on a CIA bot for commit
 messages in #openwebbeans?

 I am personally +1

any +/-0?  it's third-party (cia.vc) but it's all public info anyway.
I know HTTPD and APR both use them on freenode.

-- 
Eric Covener
cove...@gmail.com

Re: [IMPORTANT] About Big Commits

[Eric Covener]

On Sat, Jul 24, 2010 at 3:15 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 http://svn.apache.org/repos/asf/openwebbeans/trunk/readme/TCK_RUNNING.txt

Thanks Gurkan -- I ran standalone and got these results (twice) :
Tests run: 574, Failures: 10, Errors: 0, Skipped: 0, Time elapsed:
42.527 sec  FAILURE!

Results :

Failed tests:
  
testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest)
  
testRemoteInterfacesAreNotInAPITypes(org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest)
  
testBeanTypesAreLocalInterfacesWithoutWildcardTypesOrTypeVariablesWithSuperInterfaces(org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest)
  
testNewBeanHasNoBeanELName(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testNewBeanHasNoStereotypes(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testNewBeanHasNoObservers(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testForEachEnterpriseBeanANewBeanExists(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testNewBeanIsHasOnlyNewBinding(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testNewBeanIsDependentScoped(org.jboss.jsr299.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest)
  
testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest)


Is the current expectation that both web and standalone run 100%
clean, with perhaps some timing issues that cause transient failures?

I was surprised to see EJB definition tests in the standalone suite --
do you test against a tomcat+openejb that has the integration applied?
 I don't think we could figure out local interfaces only without
that (looking at testcase name only of one of the above)


-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r979071 - in /openwebbeans/trunk: webbeans-ejb/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/interceptor/ webbeans-impl/ webbeans-impl/src/main/java/org/apache/webbeans/

[Eric Covener]

Paul, can you submit a followup patch to address a few issues inline below?


 +   �...@aroundtimeout
 +    public Object callAroundTimeouts(InvocationContext context) throws 
 Exception
 +    {
 +        Object retVal = null;
 +        InjectionTargetBean? injectionTarget = (InjectionTargetBean?) 
 threadLocal.get();
 +
 +        logger.debug(OpenWebBeansEjbInterceptor: @AroundTimeout called. 
 Trying to run Interceptors.);
 +
 +        if(injectionTarget != null)
 +        {
 +            if 
 (WebBeansUtil.isContainsInterceptorMethod(injectionTarget.getInterceptorStack(),
  InterceptorType.AROUND_TIMEOUT))
 +            {
 +                InvocationContextImpl impl = new InvocationContextImpl(null, 
 context.getTarget(), null, null,
 +                        
 InterceptorUtil.getInterceptorMethods(injectionTarget.getInterceptorStack(), 
 InterceptorType.AROUND_TIMEOUT), InterceptorType.AROUND_TIMEOUT);
 +                
 impl.setCreationalContext(threadLocalCreationalContext.get());
 +                try
 +                {
 +                    //run OWB interceptors
 +                    impl.proceed();

I think something needs to be done with the return value of the 299
stack.  This does not apply to the passivation related chunks.

 +
 +                    //run EJB interceptors
 +                    retVal = context.proceed();

Please take a look at the recent restructuring of the lifecycle
interceptos == ejbcontect.proceed needs to occur outside of the
if(...intereceptor stack not empty). This does apply to the
passivation related chunks as well.

I think it is safe to a) remove the TODOS around
runPrePostForNonContextual and also to rename that routine.  If it's
used for AroundTimeout, even lifecycle is probably bad.  Maybe
runInterceptorsForNonContextualEJB or something.


-- 
Eric Covener
cove...@gmail.com

[jira] Created: (OWB-421) defined-in-class EJB lifecycle callbacks masked by our Interceptor

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

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

[Eric Covener (JIRA)]

 [ 
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

[Eric Covener (JIRA)]

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.