[jira] [Commented] (OWB-616) javax.el.ExpressionFactory has final methods! CDI doesn't allow that. - Test on final **PRIVATE** methods too?

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure commented on OWB-616:
--

I have described a workaround for this issue here on the WebSphere Application 
Server forum:
 https://www.ibm.com/developerworks/forums/thread.jspa?threadID=390668tstart=0 

 javax.el.ExpressionFactory has final methods! CDI doesn't allow that. - Test 
 on final **PRIVATE** methods too?
 --

 Key: OWB-616
 URL: https://issues.apache.org/jira/browse/OWB-616
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration
Affects Versions: 1.0.0
 Environment: IBM WebSphere Application Server 8.0.0
Reporter: Heiko Kopp
Assignee: Gurkan Erdogdu
Priority: Critical
  Labels: features

 When implementing seam-solder on WAS 8.0 one gets the following exception:
 javax.el.ExpressionFactory has final methods! CDI doesn't allow that.
   at 
 org.apache.webbeans.util.InjectionExceptionUtils.throwUnproxyableResolutionException(InjectionExceptionUtils.java:39)
   at 
 org.apache.webbeans.util.WebBeansUtil.checkUnproxiableApiType(WebBeansUtil.java:2084)
   at 
 org.apache.webbeans.config.DefinitionUtil.createProducerComponent(DefinitionUtil.java:688)
   at 
 org.apache.webbeans.config.DefinitionUtil.createProducerComponents(DefinitionUtil.java:652)
   at 
 org.apache.webbeans.config.DefinitionUtil.defineProducerMethods(DefinitionUtil.java:625)
   at 
 org.apache.webbeans.component.creation.AbstractInjectedTargetBeanCreator.defineProducerMethods(AbstractInjectedTargetBeanCreator.java:142)
   at 
 org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:3050)
   at 
 org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:881)
   at 
 org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:536)
   at 
 org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:482)
   at 
 org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:171)
   at 
 org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:124)
   at 
 org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:78)
   at 
 com.ibm.ws.webbeans.common.CommonLifeCycle.startApplication(CommonLifeCycle.java:106)
   at 
 com.ibm.ws.webbeans.services.JCDIServletContainerInitializer.onStartup(JCDIServletContainerInitializer.java:85)
   at 
 com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:609)
   at 
 com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:405)
   at 
 com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
   at 
 com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
 It turns out, that the class javax.el.ExpressionFactory shipped with the IBM 
 Application Server contains a private final method called 
 'getClassNameSysProp'. This is the method 
 org.apache.webbeans.util.WebBeansUtil.checkUnproxiableApiType() respectively 
 ClassUtil.isFinal() complains about.
 Question here is: Is CD really preventing you to define private final methods 
 or should this be reduced to public methods only?
 Thanks for clarification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-586) Interceptors added by portable extensions don't work

[Rohit Dilip Kelapure (JIRA)]

Interceptors added by portable extensions don't work


 Key: OWB-586
 URL: https://issues.apache.org/jira/browse/OWB-586
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu



The CDI Spec says During the application initialization process, the container 
fires a series of events, allowing portable extensions to integrate with the 
container initialization process. Interceptors added programatically during 
these lifecycle events are NOT added to our interceptor stack in 
org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl.addBean(Bean?).
 

In 
org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl.addBean(Bean?)
 we create a CustomInterceptor that wraps the passed interceptor.  We then add 
this CustomInterceptor to a set of 
org.apache.webbeans.container.BeanManagerImpl.webBeansInterceptors.

Unfortunately  multiple CustomInterceptor instances evaluate to the same 
hashcode and different interceptors overwrite one another when they get added 
to the Set. Consequently the right set of interceptors does not fire when a 
managed bean is to be intercepted.

The fix to this issue is for CustomInterceptor and WebBeansInterceptor to 
override the default equals and hashcode methods.

This bug causes 6 tests of the 
org.jboss.jsr299.tck.tests.interceptors.definition.custom.CustomInterceptorTest 
to FAIL.


 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-586) Interceptors added by portable extensions don't work

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-586:
-

Attachment: testCustomInterceptor.jar

I have attached the src file containing the fix in the attached jar

 Interceptors added by portable extensions don't work
 

 Key: OWB-586
 URL: https://issues.apache.org/jira/browse/OWB-586
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
  Labels: tck
 Attachments: testCustomInterceptor.jar

   Original Estimate: 24h
  Remaining Estimate: 24h

 The CDI Spec says During the application initialization process, the 
 container fires a series of events, allowing portable extensions to integrate 
 with the container initialization process. 
 In OWB, Interceptors added programatically during these lifecycle events are 
 NOT added to our interceptor stack in 
 org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl.addBean(Bean?).
  
 In 
 org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl.addBean(Bean?)
  we create a CustomInterceptor that wraps the passed interceptor.  We then 
 add this CustomInterceptor to a set of 
 org.apache.webbeans.container.BeanManagerImpl.webBeansInterceptors.
 Unfortunately  multiple CustomInterceptor instances evaluate to the same 
 hashcode and different interceptors overwrite one another when they get added 
 to the Set. Consequently the right set of interceptors does not fire when a 
 managed bean is to be intercepted.
 The fix to this issue is for CustomInterceptor and WebBeansInterceptor to 
 override the default equals and hashcode methods.
 This bug causes 6 tests of the 
 org.jboss.jsr299.tck.tests.interceptors.definition.custom.CustomInterceptorTest
  to FAIL.
  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-575) ResourceProxyHandler.invoke should unwrap and throw the underlying cause of the InvocationTargetException

[Rohit Dilip Kelapure (JIRA)]

ResourceProxyHandler.invoke should unwrap and throw the underlying cause of the 
InvocationTargetException
-

 Key: OWB-575
 URL: https://issues.apache.org/jira/browse/OWB-575
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration, TCK
Affects Versions: 1.0.0, 1.1.0
 Environment: any
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu



Right now the ResourceProxyHandler simply rethrows the exception resulting from 
an invoke.
There may be cases where the ResourceProxyHandler needs to throw the root cause 
of the exception upstream instead of the wrapped InvocationException.
ResourceProxyHandler.invoke needs to unwrap the root cause exception from the 
invoke and pass it up the chain since.
This change is conceptually similar to 
https://issues.apache.org/jira/browse/OWB-554

This defect is needed to resolve a 
org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest
 TCK failure since the TCK looks for  the IllegalStateException as noted below.
  try
  {
 entityManager.getTransaction(); // --
 entityManagerValid = false;
  }
  catch (IllegalStateException e)
  {
 // an IllegalStateException is the expected result if this is a JTA 
entityManager
}
An IllegalStateException is not caught though - because it looks like it is 
being wrapped by a java.lang.reflect.InvocationTargetException.

proposed Fix: 
@Override
public Object invoke(Object self, Method actualMethod, Method proceed, 
Object[] args) throws Throwable
{
Object rc = null;
try {

rc = actualMethod.invoke(this.actualResource, args);

} catch (InvocationTargetException ite) {
throw ite.getCause();
} catch (IllegalArgumentException e) {
throw e.getCause();
} catch (IllegalAccessException e) {
throw e.getCause();
}

return rc;
}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-575) ResourceProxyHandler.invoke should unwrap and throw the underlying cause of the InvocationTargetException

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure commented on OWB-575:
--


After looking at this some more I have changed the proposed fix to 
Should only unwrap InvocationTargetException.  The other exceptions should be 
thrown as-is since they represent coding errors.

org.apache.webbeans.proxy.ResourceProxyHandler

@Override
public Object invoke(Object self, Method actualMethod, Method proceed, 
Object[] args) throws Throwable
{
Object rc = null;
try {

rc = actualMethod.invoke(this.actualResource, args);

} catch (InvocationTargetException ite) {
throw ite.getCause();
} catch (IllegalArgumentException e) {
throw e;
} catch (IllegalAccessException e) {
throw e;
}

return rc;
}


 ResourceProxyHandler.invoke should unwrap and throw the underlying cause of 
 the InvocationTargetException
 -

 Key: OWB-575
 URL: https://issues.apache.org/jira/browse/OWB-575
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration, TCK
Affects Versions: 1.1.0, 1.0.0
 Environment: any
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
   Original Estimate: 24h
  Remaining Estimate: 24h

 Right now the ResourceProxyHandler simply rethrows the exception resulting 
 from an invoke.
 There may be cases where the ResourceProxyHandler needs to throw the root 
 cause of the exception upstream instead of the wrapped InvocationException.
 ResourceProxyHandler.invoke needs to unwrap the root cause exception from the 
 invoke and pass it up the chain since.
 This change is conceptually similar to 
 https://issues.apache.org/jira/browse/OWB-554
 This defect is needed to resolve a 
 org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest
  TCK failure since the TCK looks for  the IllegalStateException as noted 
 below.
   try
   {
  entityManager.getTransaction(); // --
  entityManagerValid = false;
   }
   catch (IllegalStateException e)
   {
  // an IllegalStateException is the expected result if this is a JTA 
 entityManager
   }
 An IllegalStateException is not caught though - because it looks like it is 
 being wrapped by a java.lang.reflect.InvocationTargetException.
 proposed Fix: 
 @Override
 public Object invoke(Object self, Method actualMethod, Method proceed, 
 Object[] args) throws Throwable
 {
   Object rc = null;
   try {
   rc = actualMethod.invoke(this.actualResource, args);
   } catch (InvocationTargetException ite) {
   throw ite.getCause();
   } catch (IllegalArgumentException e) {
   throw e.getCause();
   } catch (IllegalAccessException e) {
   throw e.getCause();
   }
   return rc;
 }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OWB-469) JSR299TCK: Security Error / Passivation errors during readObject

[Rohit Dilip Kelapure (JIRA)]

JSR299TCK: Security Error / Passivation errors during readObject


 Key: OWB-469
 URL: https://issues.apache.org/jira/browse/OWB-469
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Events
Affects Versions: 1.0.0-alpha-2, 1.1.0, 1.0.1
 Environment: win server 2003
Reporter: Rohit Dilip Kelapure
Assignee: Rohit Dilip Kelapure


JIRA opened on behalf of Paul Reder. 

Problem Observed: 

Snippet for failure:
   @SpecAssertions({
  @SpecAssertion(section = 10.3.2, id = g),
  @SpecAssertion(section = 6.6.2, id = e)
   })
   public void testImplicitEventIsPassivationCapable() throws IOException, 
ClassNotFoundException
   {
  StudentDirectory directory = getInstanceByType(StudentDirectory.class);
  directory.reset();
  Registration registration = getInstanceByType(Registration.class);
  EventStudentRegisteredEvent event = 
registration.getInjectedStudentRegisteredEvent();
  assert Serializable.class.isAssignableFrom(event.getClass());
  byte[] serializedEvent = serialize(event);
  ...
  EventStudentRegisteredEvent eventCopy = (EventStudentRegisteredEvent) 
deserialize(serializedEvent); // --- error here
  ...

Error:
java.security.AccessControlException: Access denied 
(java.lang.RuntimePermission accessClassInPackage.com.xxx.oti.reflect)
 at 
java.security.AccessController.checkPermission(AccessController.java:108)
 at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
 at 
com.xxx.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
 at 
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1528)
 at 
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:343)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
 at 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
 at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
 at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
 at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:103)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
 at java.lang.Class.forNameImpl(Native Method)
 at java.lang.Class.forName(Class.java:169)
 at 
java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:605)
 at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1559)
 at 
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1500)
 at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736)
 at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
 at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
 at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1875)
 at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
 at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
 at 
java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
 at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
 at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
 at 
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:481)
 at 
org.apache.webbeans.event.EventImpl.readObject(EventImpl.java:153)
 at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1033)
 at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1853)
 at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
 at 
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
 at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:352)
 at 
org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63)
 at 
org.jboss.jsr299.tck.tests.event.implicit.ImplicitEventTest.testImplicitEventIsPassivationCapable(ImplicitEventTest.java:118)

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

[jira] Updated: (OWB-469) JSR299TCK: Security Error / Passivation errors during readObject

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-469:
-


Patch provided by Paul Reder

 JSR299TCK: Security Error / Passivation errors during readObject
 

 Key: OWB-469
 URL: https://issues.apache.org/jira/browse/OWB-469
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Events
Affects Versions: 1.1.0, 1.0.1, 1.0.0-alpha-2
 Environment: win server 2003
Reporter: Rohit Dilip Kelapure
Assignee: Rohit Dilip Kelapure
   Original Estimate: 24h
  Remaining Estimate: 24h

 JIRA opened on behalf of Paul Reder. 
 Problem Observed: 
 Snippet for failure:
@SpecAssertions({
   @SpecAssertion(section = 10.3.2, id = g),
   @SpecAssertion(section = 6.6.2, id = e)
})
public void testImplicitEventIsPassivationCapable() throws IOException, 
 ClassNotFoundException
{
   StudentDirectory directory = getInstanceByType(StudentDirectory.class);
   directory.reset();
   Registration registration = getInstanceByType(Registration.class);
   EventStudentRegisteredEvent event = 
 registration.getInjectedStudentRegisteredEvent();
   assert Serializable.class.isAssignableFrom(event.getClass());
   byte[] serializedEvent = serialize(event);
   ...
   EventStudentRegisteredEvent eventCopy = 
 (EventStudentRegisteredEvent) deserialize(serializedEvent); // --- error 
 here
   ...
 Error:
 java.security.AccessControlException: Access denied 
 (java.lang.RuntimePermission accessClassInPackage.com.xxx.oti.reflect)
at 
 java.security.AccessController.checkPermission(AccessController.java:108)
at 
 java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
at 
 com.xxx.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
at 
 java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1528)
at 
 sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:343)
at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:103)
at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:169)
at 
 java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:605)
at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1559)
at 
 java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1500)
at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736)
at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
at 
 java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1875)
at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
at 
 java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1951)
at 
 java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:481)
at 
 org.apache.webbeans.event.EventImpl.readObject(EventImpl.java:153)
at 
 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1033)
at 
 java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1853)
at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1757)
at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
at 
 java.io.ObjectInputStream.readObject(ObjectInputStream.java:352)
at 
 org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63)
at 
 org.jboss.jsr299.tck.tests.event.implicit.ImplicitEventTest.testImplicitEventIsPassivationCapable(ImplicitEventTest.java:118)

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

[jira] Updated: (OWB-468) Make BeansDeployer.deployFromClassPath(ScannerService) resilient to ClassNotFoundException and NoClassDefFoundError's

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-468:
-

Description: 

In tiered  classloading environments, lifecycle start -- BeansDeployer deploy 
-- AnnotatedElementFactory.newAnnotatedType(ClassX) sometimes throws 
ClassNotFoundException and NoClassDefFoundError's from the following methods 
  Field[] fields = SecurityUtil.doPrivilegedGetDeclaredFields(annotatedClass);
  Method[] methods = 
SecurityUtil.doPrivilegedGetDeclaredMethods(annotatedClass);
  These exceptions and errors are typically due to incorrect or erroneous 
application packaging of classes and dependencies. 

I would like OpenWebBeans to continue loading other classes even if one/few 
classes cannot be loaded correctly i.e. the assumption is that we don't punish 
the majority for the crimes of a few. We define Managed Beans ONLY for classes 
that yield a AnnotatedType. 

At runtime, if the application exercises any CDI function on the bad classes, 
then the results are indeterminate.
I will attach a patch that will explain my approach of fixing this. 


java.lang.NoClassDefFoundError: com.example svt.acme.AnnuityMgmt
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:260)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
at 
com.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:803)
at 
com.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:718)
at 
com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:541)
at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
at 
com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:539)
at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:674)
at 
org.apache.webbeans.util.SecurityUtil$PrivilegedActionForClass.run(SecurityUtil.java:137)
at 
java.security.AccessController.doPrivileged(AccessController.java:203)
at 
org.apache.webbeans.util.SecurityUtil.doPrivilegedGetDeclaredMethods(SecurityUtil.java:84)
at 
org.apache.webbeans.portable.AnnotatedElementFactory.newAnnotatedType(AnnotatedElementFactory.java:102)

  was:

Sometimes in tiered  classloading environments during lifecycle start -- 
BeansDeployer deploy -- AnnotatedElementFactory.newAnnotatedType(ClassX) 
throws ClassNotFoundException and NoClassDefFoundError's from the following 
methods 
  Field[] fields = SecurityUtil.doPrivilegedGetDeclaredFields(annotatedClass);
  Method[] methods = 
SecurityUtil.doPrivilegedGetDeclaredMethods(annotatedClass);
  These exceptions and errors are typically due to incorrect or erroneous 
application packaging of classes and dependencies. 

I would like OpenWebBeans to continue loading other classes even if one/few 
classes cannot be loaded correctly i.e. the assumption is that we don't punish 
the majority for the crimes of a few. We define Managed Beans ONLY for classes 
that yield a AnnotatedType. 

At runtime, if the application exercises any CDI function on the bad classes, 
then the results are indeterminate.
I will attach a patch that will explain my approach of fixing this. 


java.lang.NoClassDefFoundError: com.example svt.acme.AnnuityMgmt
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:260)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
at 
com.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:803)
at 
com.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:718)
at 
com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:541)
at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
at 
com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:539)
at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:674)
at 
org.apache.webbeans.util.SecurityUtil$PrivilegedActionForClass.run(SecurityUtil.java:137)
at 
java.security.AccessController.doPrivileged(AccessController.java:203)
at 
org.apache.webbeans.util.SecurityUtil.doPrivilegedGetDeclaredMethods(SecurityUtil.java:84)
at 
org.apache.webbeans.portable.AnnotatedElementFactory.newAnnotatedType(AnnotatedElementFactory.java:102)


 Make BeansDeployer.deployFromClassPath(ScannerService) resilient to 
 ClassNotFoundException and NoClassDefFoundError's
 

[jira] Updated: (OWB-468) Make BeansDeployer.deployFromClassPath(ScannerService) resilient to ClassNotFoundException and NoClassDefFoundError's

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-468:
-

Attachment: owb-468.patch

Attaching a patch for this issue to explain my approach for fixing this issue 
and to elicit feedback.

 Make BeansDeployer.deployFromClassPath(ScannerService) resilient to 
 ClassNotFoundException and NoClassDefFoundError's
 -

 Key: OWB-468
 URL: https://issues.apache.org/jira/browse/OWB-468
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core, Java EE Integration, Lifecycle
Affects Versions: 1.1.0, 1.0.1, 1.0.0, 1.0.0-alpha-2
 Environment: Windows Server 2003
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
 Attachments: owb-468.patch


 In tiered  classloading environments, lifecycle start -- BeansDeployer 
 deploy -- AnnotatedElementFactory.newAnnotatedType(ClassX) sometimes 
 throws ClassNotFoundException and NoClassDefFoundError's from the following 
 methods 
   Field[] fields = SecurityUtil.doPrivilegedGetDeclaredFields(annotatedClass);
   Method[] methods = 
 SecurityUtil.doPrivilegedGetDeclaredMethods(annotatedClass);
   These exceptions and errors are typically due to incorrect or erroneous 
 application packaging of classes and dependencies. 
 I would like OpenWebBeans to continue loading other classes even if one/few 
 classes cannot be loaded correctly i.e. the assumption is that we don't 
 punish the majority for the crimes of a few. We define Managed Beans ONLY for 
 classes that yield a AnnotatedType. 
 At runtime, if the application exercises any CDI function on the bad 
 classes, then the results are indeterminate.
 I will attach a patch that will explain my approach of fixing this. 
 java.lang.NoClassDefFoundError: com.example svt.acme.AnnuityMgmt
   at java.lang.ClassLoader.defineClassImpl(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:260)
   at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
   at 
 com.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:803)
   at 
 com.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:718)
   at 
 com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:541)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
   at 
 com.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:539)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:612)
   at java.lang.Class.getDeclaredMethodsImpl(Native Method)
   at java.lang.Class.getDeclaredMethods(Class.java:674)
   at 
 org.apache.webbeans.util.SecurityUtil$PrivilegedActionForClass.run(SecurityUtil.java:137)
   at 
 java.security.AccessController.doPrivileged(AccessController.java:203)
   at 
 org.apache.webbeans.util.SecurityUtil.doPrivilegedGetDeclaredMethods(SecurityUtil.java:84)
   at 
 org.apache.webbeans.portable.AnnotatedElementFactory.newAnnotatedType(AnnotatedElementFactory.java:102)

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

[jira] Created: (OWB-456) When multiple interceptors are defined for a bean OWB does NOT correctly remove the overriden base Interceptors

[Rohit Dilip Kelapure (JIRA)]

When multiple interceptors  are defined for a bean OWB does NOT correctly  
remove the overriden base Interceptors 
--

 Key: OWB-456
 URL: https://issues.apache.org/jira/browse/OWB-456
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0-alpha-3
 Environment: Windows Server 2003 
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-GA, 1.0.0-alpha-4


OWB does not remove the overriden parent interceptor from the Interceptor stack 
of a bean leading to TCK failures like these ... 

@Test
   @SpecAssertions({
  @SpecAssertion(section = 1, id = i),
  @SpecAssertion(section = 3, id= b),
  @SpecAssertion(section = 3.1, id= c),
  @SpecAssertion(section = 3.1, id= d),
  @SpecAssertion(section = 3.1, id= e),
  @SpecAssertion(section = 3.1, id= f),
  @SpecAssertion(section = 3.1, id= g),
  @SpecAssertion(section = 8, id = e)
   })
   public void testInvocationOrder() {
  ...
  assert !Interceptor1.isOverridenMethodCalled();  // Error here
   }

Error:
java.lang.AssertionError
at 
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

In this case
@Interceptors( { Interceptor1.class, Interceptor3.class })
class Tram extends RailVehicle  {
}

Inspite of Interceptor1 overriding OverridenInterceptor we see  
OverridenInterceptor.intercept being called.
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest 
is the failing TCK test. 

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

[jira] Updated: (OWB-456) When multiple interceptors are defined for a bean OWB does NOT correctly remove the overriden base Interceptors

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-456:
-

Description: 
EJB 3.0 spec. mandates that 
- If a bean class has superclasses, any AroundInvoke methods defined on those 
superclasses are invoked, most general superclass first.
- If an AroundInvoke method is overridden by another method (regardless of 
whether that method is itself an AroundInvoke method), it will not be invoked 

In some cases OWB does not remove the overriden parent interceptor from the 
Interceptor stack of a bean leading to TCK failures like these ... 

@Test
   @SpecAssertions({
  @SpecAssertion(section = 1, id = i),
  @SpecAssertion(section = 3, id= b),
  @SpecAssertion(section = 3.1, id= c),
  @SpecAssertion(section = 3.1, id= d),
  @SpecAssertion(section = 3.1, id= e),
  @SpecAssertion(section = 3.1, id= f),
  @SpecAssertion(section = 3.1, id= g),
  @SpecAssertion(section = 8, id = e)
   })
   public void testInvocationOrder() {
  ...
  assert !Interceptor1.isOverridenMethodCalled();  // Error here
   }

Error:
java.lang.AssertionError
at 
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

In this case
@Interceptors( { Interceptor1.class, Interceptor3.class })
class Tram extends RailVehicle  {
}

Inspite of Interceptor1 overriding OverridenInterceptor we see  
OverridenInterceptor.intercept being called.
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest 
is the failing TCK test. 

  was:
EJB 3.0 spec. mandates that 
- If a bean class has superclasses, any AroundInvoke methods defined on those 
superclasses are invoked, most general superclass first.

In some cases OWB does not remove the overriden parent interceptor from the 
Interceptor stack of a bean leading to TCK failures like these ... 

@Test
   @SpecAssertions({
  @SpecAssertion(section = 1, id = i),
  @SpecAssertion(section = 3, id= b),
  @SpecAssertion(section = 3.1, id= c),
  @SpecAssertion(section = 3.1, id= d),
  @SpecAssertion(section = 3.1, id= e),
  @SpecAssertion(section = 3.1, id= f),
  @SpecAssertion(section = 3.1, id= g),
  @SpecAssertion(section = 8, id = e)
   })
   public void testInvocationOrder() {
  ...
  assert !Interceptor1.isOverridenMethodCalled();  // Error here
   }

Error:
java.lang.AssertionError
at 
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

In this case
@Interceptors( { Interceptor1.class, Interceptor3.class })
class Tram extends RailVehicle  {
}

Inspite of Interceptor1 overriding OverridenInterceptor we see  
OverridenInterceptor.intercept being called.
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest 
is the failing TCK test. 


 When multiple interceptors  are defined for a bean OWB does NOT correctly  
 remove the overriden base Interceptors 
 --

 Key: OWB-456
 URL: https://issues.apache.org/jira/browse/OWB-456
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0-alpha-3
 Environment: Windows Server 2003 
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-GA, 1.0.0-alpha-4

   Original Estimate: 24h
  Remaining Estimate: 24h

 EJB 3.0 spec. mandates that 
 - If a bean class has superclasses, any AroundInvoke methods defined on those 
 superclasses are invoked, most general superclass first.
 - If an AroundInvoke method is overridden by another method (regardless of 
 whether that method is itself an AroundInvoke method), it will not be invoked 
 In some cases OWB does not remove the overriden parent interceptor from the 
 Interceptor stack of a bean leading to TCK failures like these ... 
 @Test
@SpecAssertions({
   @SpecAssertion(section = 1, id = i),
   @SpecAssertion(section = 3, id= b),
   @SpecAssertion(section = 3.1, id= c),
   @SpecAssertion(section = 3.1, id= d),
   @SpecAssertion(section = 3.1, id= e),
   @SpecAssertion(section = 3.1, id= f),
   @SpecAssertion(section = 3.1, id= g),
   @SpecAssertion(section = 8, id = e)
})
public void testInvocationOrder() {
   ...
   assert !Interceptor1.isOverridenMethodCalled();  // Error here
}
 Error:
 java.lang.AssertionError
   at 
 

[jira] Updated: (OWB-456) When multiple interceptors are defined for a bean OWB does NOT correctly remove the overriden base Interceptors

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-456:
-

Description: 
EJB 3.0 spec. mandates that 
- If a bean class has superclasses, any AroundInvoke methods defined on those 
superclasses are invoked, most general superclass first.

In some cases OWB does not remove the overriden parent interceptor from the 
Interceptor stack of a bean leading to TCK failures like these ... 

@Test
   @SpecAssertions({
  @SpecAssertion(section = 1, id = i),
  @SpecAssertion(section = 3, id= b),
  @SpecAssertion(section = 3.1, id= c),
  @SpecAssertion(section = 3.1, id= d),
  @SpecAssertion(section = 3.1, id= e),
  @SpecAssertion(section = 3.1, id= f),
  @SpecAssertion(section = 3.1, id= g),
  @SpecAssertion(section = 8, id = e)
   })
   public void testInvocationOrder() {
  ...
  assert !Interceptor1.isOverridenMethodCalled();  // Error here
   }

Error:
java.lang.AssertionError
at 
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

In this case
@Interceptors( { Interceptor1.class, Interceptor3.class })
class Tram extends RailVehicle  {
}

Inspite of Interceptor1 overriding OverridenInterceptor we see  
OverridenInterceptor.intercept being called.
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest 
is the failing TCK test. 

  was:
OWB does not remove the overriden parent interceptor from the Interceptor stack 
of a bean leading to TCK failures like these ... 

@Test
   @SpecAssertions({
  @SpecAssertion(section = 1, id = i),
  @SpecAssertion(section = 3, id= b),
  @SpecAssertion(section = 3.1, id= c),
  @SpecAssertion(section = 3.1, id= d),
  @SpecAssertion(section = 3.1, id= e),
  @SpecAssertion(section = 3.1, id= f),
  @SpecAssertion(section = 3.1, id= g),
  @SpecAssertion(section = 8, id = e)
   })
   public void testInvocationOrder() {
  ...
  assert !Interceptor1.isOverridenMethodCalled();  // Error here
   }

Error:
java.lang.AssertionError
at 
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

In this case
@Interceptors( { Interceptor1.class, Interceptor3.class })
class Tram extends RailVehicle  {
}

Inspite of Interceptor1 overriding OverridenInterceptor we see  
OverridenInterceptor.intercept being called.
org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest 
is the failing TCK test. 


 When multiple interceptors  are defined for a bean OWB does NOT correctly  
 remove the overriden base Interceptors 
 --

 Key: OWB-456
 URL: https://issues.apache.org/jira/browse/OWB-456
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0-alpha-3
 Environment: Windows Server 2003 
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-GA, 1.0.0-alpha-4

   Original Estimate: 24h
  Remaining Estimate: 24h

 EJB 3.0 spec. mandates that 
 - If a bean class has superclasses, any AroundInvoke methods defined on those 
 superclasses are invoked, most general superclass first.
 In some cases OWB does not remove the overriden parent interceptor from the 
 Interceptor stack of a bean leading to TCK failures like these ... 
 @Test
@SpecAssertions({
   @SpecAssertion(section = 1, id = i),
   @SpecAssertion(section = 3, id= b),
   @SpecAssertion(section = 3.1, id= c),
   @SpecAssertion(section = 3.1, id= d),
   @SpecAssertion(section = 3.1, id= e),
   @SpecAssertion(section = 3.1, id= f),
   @SpecAssertion(section = 3.1, id= g),
   @SpecAssertion(section = 8, id = e)
})
public void testInvocationOrder() {
   ...
   assert !Interceptor1.isOverridenMethodCalled();  // Error here
}
 Error:
 java.lang.AssertionError
   at 
 org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 In this case
 @Interceptors( { Interceptor1.class, Interceptor3.class })
 class Tram extends RailVehicle  {
 }
 Inspite of Interceptor1 overriding OverridenInterceptor we see  
 OverridenInterceptor.intercept being called.
 org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest
  is the failing TCK test.   

-- 
This message is automatically generated by JIRA.
-
You 

[jira] Updated: (OWB-456) When multiple interceptors are defined for a bean OWB does NOT correctly remove the overriden base Interceptors

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-456:
-

Attachment: OWB-456.patch

After running with this patch I see the following results with logging enabled

PASSED: testInvocationOrder
===

org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest
Tests run: 1, Failures: 0, Skips: 0
===


openwebbeansmvn test
Results :
Failed tests:
  
testInterceptorPerformance(org.apache.webbeans.newtests.interceptors.business.tests.InterceptorPerformanceTest)
Tests run: 263, Failures: 1, Errors: 0, Skipped: 1

Web Profile TCK
==
JSR-299 TCK
Tests run: 513, Failures: 0, Skips: 0
===

STANDALONE TCK
===
JSR-299 TCK
Tests run: 574, Failures: 0, Skips: 0
===







 When multiple interceptors  are defined for a bean OWB does NOT correctly  
 remove the overriden base Interceptors 
 --

 Key: OWB-456
 URL: https://issues.apache.org/jira/browse/OWB-456
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: 1.0.0-alpha-3
 Environment: Windows Server 2003 
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-GA, 1.0.0-alpha-4

 Attachments: OWB-456.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 EJB 3.0 spec. mandates that 
 - If a bean class has superclasses, any AroundInvoke methods defined on those 
 superclasses are invoked, most general superclass first.
 - If an AroundInvoke method is overridden by another method (regardless of 
 whether that method is itself an AroundInvoke method), it will not be invoked 
 In some cases OWB does not remove the overriden parent interceptor from the 
 Interceptor stack of a bean leading to TCK failures like these ... 
 @Test
@SpecAssertions({
   @SpecAssertion(section = 1, id = i),
   @SpecAssertion(section = 3, id= b),
   @SpecAssertion(section = 3.1, id= c),
   @SpecAssertion(section = 3.1, id= d),
   @SpecAssertion(section = 3.1, id= e),
   @SpecAssertion(section = 3.1, id= f),
   @SpecAssertion(section = 3.1, id= g),
   @SpecAssertion(section = 8, id = e)
})
public void testInvocationOrder() {
   ...
   assert !Interceptor1.isOverridenMethodCalled();  // Error here
}
 Error:
 java.lang.AssertionError
   at 
 org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest.testInvocationOrder(InvocationOrderTest.java:43)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 In this case
 @Interceptors( { Interceptor1.class, Interceptor3.class })
 class Tram extends RailVehicle  {
 }
 Inspite of Interceptor1 overriding OverridenInterceptor we see  
 OverridenInterceptor.intercept being called.
 org.jboss.jsr299.tck.interceptors.tests.aroundInvoke.order.InvocationOrderTest
  is the failing TCK test.   

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

[jira] Created: (OWB-423) OpenWebBeansEjbInterceptor is LATE is in establishing the request context for an EJB

[Rohit Dilip Kelapure (JIRA)]

OpenWebBeansEjbInterceptor is LATE is in establishing the request context for 
an EJB


 Key: OWB-423
 URL: https://issues.apache.org/jira/browse/OWB-423
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration
Affects Versions: M1, M2, M3, M4, 1.1.0, 1.0.0-GA, 1.0.0-alpha-4, 
1.0.0-alpha-3, 1.0.0-alpha-2, 1.0.0-alpha-1
 Environment: Win2003 Server
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu


The CDI specification in 6.7.1. Request context lifecycle states that the  
request scope is active during any remote method invocation of any EJB, during 
any asynchronous method invocation of any EJB, during any call to an EJB 
timeout method and during message delivery to any EJB message-driven bean, and 
during any message delivery to a MessageListener for a JMS topic or queue 
obtained from the Java EE component environment.

Currently  the OpenWebBeansEjbInterceptor  does two broad things
- activate and deactive request and application contexts
- call OWB Interceptors and decorators applicable to the EJB

This doesn't work correctly if a request scoped bean is injected in an old 
style JEE5 EJB interceptor. According to the spec. the old EJB interceptors run 
before the JSR299 interceptors and decorators. However there is no request 
scope when a CDI injection occurs in the EJB interceptor because the request 
scope is established LATER by the OpenWebBeansEjbInterceptor   after all the 
EJB interceptors have run.

This results in an exception like this ..
javax.ejb.EJBException: Injection failure; nested exception is: 
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope 
type annotation @RequestScoped does not exist within current thread
Caused by: javax.enterprise.context.ContextNotActiveException: WebBeans context 
with scope type annotation @RequestScoped does not exist within current thread
at 
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:123)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:94)
at 
com.ibm.ws.fat.jcdi.beans.CurrentUser_$$_javassist_4.toString(CurrentUser_$$_javassist_4.java)


The solution to this problem is to take a sandwich approach to configuring 
interceptors.  i.e Split OpenWebBeansEjbInterceptor   into two
 FirstEJBInterceptor   establishes and tears down request and application 
context
 EJB Interceptor-1
 EJB Interceptor- 2
 OpenWebBeansEjbInterceptor ..  setsup the JCDI runtime to call OWB 
Interceptors and decorators applicable to the EJB
 OWB Interceptor-1
 OWB decorator

The FirstEJBInterceptor is responsible  for ensuring the request context is 
active during requests to EJBs and has to be innermost or the first interceptor 
in the stack for all EJBs. Without this interceptor Apache OWB cannot do 
injection of request scoped or application scoped beans in the older JEE5 EJB 
Interceptors. 

--Thank You



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

[jira] Updated: (OWB-423) OpenWebBeansEjbInterceptor is LATE in establishing the request context for an EJB

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-423:
-

Summary: OpenWebBeansEjbInterceptor is LATE in establishing the request 
context for an EJB  (was: OpenWebBeansEjbInterceptor is LATE is in establishing 
the request context for an EJB)

 OpenWebBeansEjbInterceptor is LATE in establishing the request context for an 
 EJB
 -

 Key: OWB-423
 URL: https://issues.apache.org/jira/browse/OWB-423
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration
Affects Versions: 1.1.0, 1.0.0-GA, 1.0.0-alpha-4, 1.0.0-alpha-3, 
 1.0.0-alpha-2, 1.0.0-alpha-1, M4, M3, M2, M1
 Environment: Win2003 Server
Reporter: Rohit Dilip Kelapure
Assignee: Gurkan Erdogdu
   Original Estimate: 24h
  Remaining Estimate: 24h

 The CDI specification in 6.7.1. Request context lifecycle states that the  
 request scope is active during any remote method invocation of any EJB, 
 during any asynchronous method invocation of any EJB, during any call to an 
 EJB timeout method and during message delivery to any EJB message-driven 
 bean, and during any message delivery to a MessageListener for a JMS topic or 
 queue obtained from the Java EE component environment.
 Currently  the OpenWebBeansEjbInterceptor  does two broad things
 - activate and deactive request and application contexts
 - call OWB Interceptors and decorators applicable to the EJB
 This doesn't work correctly if a request scoped bean is injected in an old 
 style JEE5 EJB interceptor. According to the spec. the old EJB interceptors 
 run before the JSR299 interceptors and decorators. However there is no 
 request scope when a CDI injection occurs in the EJB interceptor because the 
 request scope is established LATER by the OpenWebBeansEjbInterceptor   after 
 all the EJB interceptors have run.
 This results in an exception like this ..
 javax.ejb.EJBException: Injection failure; nested exception is: 
 javax.enterprise.context.ContextNotActiveException: WebBeans context with 
 scope type annotation @RequestScoped does not exist within current thread
 Caused by: javax.enterprise.context.ContextNotActiveException: WebBeans 
 context with scope type annotation @RequestScoped does not exist within 
 current thread
   at 
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
   at 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:123)
   at 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:94)
   at 
 com.ibm.ws.fat.jcdi.beans.CurrentUser_$$_javassist_4.toString(CurrentUser_$$_javassist_4.java)
 The solution to this problem is to take a sandwich approach to configuring 
 interceptors.  i.e Split OpenWebBeansEjbInterceptor   into two
  FirstEJBInterceptor   establishes and tears down request and application 
 context
  EJB Interceptor-1
  EJB Interceptor- 2
  OpenWebBeansEjbInterceptor ..  setsup the JCDI runtime to call OWB 
 Interceptors and decorators applicable to the EJB
  OWB Interceptor-1
  OWB decorator
 The FirstEJBInterceptor is responsible  for ensuring the request context is 
 active during requests to EJBs and has to be innermost or the first 
 interceptor in the stack for all EJBs. Without this interceptor Apache OWB 
 cannot do injection of request scoped or application scoped beans in the 
 older JEE5 EJB Interceptors. 
 --Thank You

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

[jira] Updated: (OWB-423) OpenWebBeansEjbInterceptor is LATE in establishing the request context for an EJB

[Rohit Dilip Kelapure (JIRA)]

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

Rohit Dilip Kelapure updated OWB-423:
-

Description: 
The CDI specification in 6.7.1. Request context lifecycle states that the  
request scope is active during any remote method invocation of any EJB, during 
any asynchronous method invocation of any EJB, during any call to an EJB 
timeout method and during message delivery to any EJB message-driven bean, and 
during any message delivery to a MessageListener for a JMS topic or queue 
obtained from the Java EE component environment.

Currently  the OpenWebBeansEjbInterceptor  does two broad things
- activate and deactive request and application contexts
- call OWB Interceptors and decorators applicable to the EJB

This doesn't work correctly if a request scoped bean is injected in an old 
style JEE5 EJB interceptor. According to the spec. the old EJB interceptors run 
before the JSR299 interceptors and decorators. However there is no request 
scope when a CDI injection occurs in the EJB interceptor because the request 
scope is established LATER by the OpenWebBeansEjbInterceptor   after all the 
EJB interceptors have run.

This results in an exception like this ..
javax.ejb.EJBException: Injection failure; nested exception is: 
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope 
type annotation @RequestScoped does not exist within current thread
Caused by: javax.enterprise.context.ContextNotActiveException: WebBeans context 
with scope type annotation @RequestScoped does not exist within current thread
at 
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:123)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:94)
at 
com.ibm.ws.fat.jcdi.beans.CurrentUser_$$_javassist_4.toString(CurrentUser_$$_javassist_4.java)


The solution to this problem is to take a sandwich approach to configuring 
interceptors.  i.e Split OpenWebBeansEjbInterceptor   into two
 FirstEJBInterceptor   establishes and tears down OWB request and 
application context
 EJB Interceptor-1
 EJB Interceptor- 2
 OpenWebBeansEjbInterceptor ..  setsup the JCDI runtime to call OWB 
Interceptors and decorators applicable to the EJB
 OWB Interceptor-1
 OWB decorator

The FirstEJBInterceptor is responsible  for ensuring the request context is 
active during requests to EJBs and has to be innermost or the first interceptor 
in the stack for all EJBs. Without this interceptor Apache OWB cannot do 
injection of request scoped or application scoped beans in the older JEE5 EJB 
Interceptors. 

--Thank You



  was:
The CDI specification in 6.7.1. Request context lifecycle states that the  
request scope is active during any remote method invocation of any EJB, during 
any asynchronous method invocation of any EJB, during any call to an EJB 
timeout method and during message delivery to any EJB message-driven bean, and 
during any message delivery to a MessageListener for a JMS topic or queue 
obtained from the Java EE component environment.

Currently  the OpenWebBeansEjbInterceptor  does two broad things
- activate and deactive request and application contexts
- call OWB Interceptors and decorators applicable to the EJB

This doesn't work correctly if a request scoped bean is injected in an old 
style JEE5 EJB interceptor. According to the spec. the old EJB interceptors run 
before the JSR299 interceptors and decorators. However there is no request 
scope when a CDI injection occurs in the EJB interceptor because the request 
scope is established LATER by the OpenWebBeansEjbInterceptor   after all the 
EJB interceptors have run.

This results in an exception like this ..
javax.ejb.EJBException: Injection failure; nested exception is: 
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope 
type annotation @RequestScoped does not exist within current thread
Caused by: javax.enterprise.context.ContextNotActiveException: WebBeans context 
with scope type annotation @RequestScoped does not exist within current thread
at 
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:123)
at 
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:94)
at 
com.ibm.ws.fat.jcdi.beans.CurrentUser_$$_javassist_4.toString(CurrentUser_$$_javassist_4.java)


The solution to this problem is to take a sandwich approach to configuring 
interceptors.  i.e Split OpenWebBeansEjbInterceptor   into two