[jira] [Commented] (OWB-1123) NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435847#comment-15435847
 ] 

Leonardo Uribe commented on OWB-1123:
-

It should be possible to reproduce the problem without JSF

> NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization
> 
>
> Key: OWB-1123
> URL: https://issues.apache.org/jira/browse/OWB-1123
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: TomEE 7.0.0.M2
>Reporter: Bauke Scholtz
>Assignee: Mark Struberg
>
> Imagine a session scoped bean which has an application scoped bean injected 
> as property and it's being referenced in {{readObject()}}.
> {code}
> @SessionScoped
> public class SessionScopedBean {
> @Inject
> private ApplicationScopedBean appBean;
> private void readObject(ObjectInputStream input) throws IOException, 
> ClassNotFoundException {
> appBean.doSomething();
> }
> }
> {code}
> OWB 1.6.2 as used in TomEE 7.0.0.M2 throws below exception when TomEE is 
> restarted with session persistence (and above bean is created during that 
> session):
> {code}
> java.lang.NullPointerException
> at 
> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:121)
> at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.readResolve(NormalScopedBeanInterceptorHandler.java:125)
> {code}
> It works fine in all Weld 2.x versions I tested so far (WF8/9/10, PY4 and 
> "plain" Tomcat8+Weld 2.3.0).
> Work around would be to use a static method on application scoped bean, but 
> this is not nice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OWB-1123) NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435837#comment-15435837
 ] 

Leonardo Uribe edited comment on OWB-1123 at 8/24/16 10:21 PM:
---

I can see that org.apache.myfaces.cdi.view.ViewScopeBeanHolder is the session 
scope bean that has the reference. The problem is in OWB, the use of 
@ViewScoped trigger the use of this bean (because this bean is the one that 
holds the view scope bean info), but if the deserialization happens on the 
right place, ApplicationContextBean should be available. The problem I see is 
the deserialisation step could happen outside CDI control, and OWB must ensure 
that case to work (the bean in that case must be resolved in a lazy way). In 
previous OWB versions, there was a wrapper over the beans, and I guess that 
wrapper had a logic to avoid that case. 


was (Author: lu4242):
I can that org.apache.myfaces.cdi.view.ViewScopeBeanHolder is the session scope 
bean that has the reference. The problem is in OWB, the use of @ViewScoped 
trigger the use of this bean (because this bean is the one that holds the view 
scope bean info), but if the deserialization happens on the right place, 
ApplicationContextBean should be available. The problem I see is the 
deserialisation step could happen outside CDI control, and OWB must ensure that 
case to work (the bean in that case must be resolved in a lazy way). In 
previous OWB versions, there was a wrapper over the beans, and I guess that 
wrapper had a logic to avoid that case. 

> NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization
> 
>
> Key: OWB-1123
> URL: https://issues.apache.org/jira/browse/OWB-1123
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: TomEE 7.0.0.M2
>Reporter: Bauke Scholtz
>Assignee: Mark Struberg
>
> Imagine a session scoped bean which has an application scoped bean injected 
> as property and it's being referenced in {{readObject()}}.
> {code}
> @SessionScoped
> public class SessionScopedBean {
> @Inject
> private ApplicationScopedBean appBean;
> private void readObject(ObjectInputStream input) throws IOException, 
> ClassNotFoundException {
> appBean.doSomething();
> }
> }
> {code}
> OWB 1.6.2 as used in TomEE 7.0.0.M2 throws below exception when TomEE is 
> restarted with session persistence (and above bean is created during that 
> session):
> {code}
> java.lang.NullPointerException
> at 
> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:121)
> at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.readResolve(NormalScopedBeanInterceptorHandler.java:125)
> {code}
> It works fine in all Weld 2.x versions I tested so far (WF8/9/10, PY4 and 
> "plain" Tomcat8+Weld 2.3.0).
> Work around would be to use a static method on application scoped bean, but 
> this is not nice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OWB-1123) NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435837#comment-15435837
 ] 

Leonardo Uribe commented on OWB-1123:
-

I can that org.apache.myfaces.cdi.view.ViewScopeBeanHolder is the session scope 
bean that has the reference. The problem is in OWB, the use of @ViewScoped 
trigger the use of this bean (because this bean is the one that holds the view 
scope bean info), but if the deserialization happens on the right place, 
ApplicationContextBean should be available. The problem I see is the 
deserialisation step could happen outside CDI control, and OWB must ensure that 
case to work (the bean in that case must be resolved in a lazy way). In 
previous OWB versions, there was a wrapper over the beans, and I guess that 
wrapper had a logic to avoid that case. 

> NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization
> 
>
> Key: OWB-1123
> URL: https://issues.apache.org/jira/browse/OWB-1123
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: TomEE 7.0.0.M2
>Reporter: Bauke Scholtz
>Assignee: Mark Struberg
>
> Imagine a session scoped bean which has an application scoped bean injected 
> as property and it's being referenced in {{readObject()}}.
> {code}
> @SessionScoped
> public class SessionScopedBean {
> @Inject
> private ApplicationScopedBean appBean;
> private void readObject(ObjectInputStream input) throws IOException, 
> ClassNotFoundException {
> appBean.doSomething();
> }
> }
> {code}
> OWB 1.6.2 as used in TomEE 7.0.0.M2 throws below exception when TomEE is 
> restarted with session persistence (and above bean is created during that 
> session):
> {code}
> java.lang.NullPointerException
> at 
> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:121)
> at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.readResolve(NormalScopedBeanInterceptorHandler.java:125)
> {code}
> It works fine in all Weld 2.x versions I tested so far (WF8/9/10, PY4 and 
> "plain" Tomcat8+Weld 2.3.0).
> Work around would be to use a static method on application scoped bean, but 
> this is not nice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OWB-1123) NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15398751#comment-15398751
 ] 

Leonardo Uribe commented on OWB-1123:
-

I see. I have tested already if ViewScopeContextualStorage can be serialized 
and I can't see any problem there. MyFaces uses a CDI session scope bean to 
hold the view scopes (ViewScopeBeanHolder).

I think it should be some instance that is not serializable inside 
ViewScopeContextualStorage but that comes from CDI. With the previous method, I 
guess everything was packed somehow to be serialized later. If that instance is 
not serializable, it is just skipped on serialization but it lets a null on 
deserialization and throw the null pointer exception. There is a call to 
java.util.HashMap.readObject(...) in the stack trace, so it is something inside:

private final Map contextualInstances;

or

private final Map nameBeanKeyMap;


> NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization
> 
>
> Key: OWB-1123
> URL: https://issues.apache.org/jira/browse/OWB-1123
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: TomEE 7.0.0.M2
>Reporter: Bauke Scholtz
>Assignee: Mark Struberg
>
> Imagine a session scoped bean which has an application scoped bean injected 
> as property and it's being referenced in {{readObject()}}.
> {code}
> @SessionScoped
> public class SessionScopedBean {
> @Inject
> private ApplicationScopedBean appBean;
> private void readObject(ObjectInputStream input) throws IOException, 
> ClassNotFoundException {
> appBean.doSomething();
> }
> }
> {code}
> OWB 1.6.2 as used in TomEE 7.0.0.M2 throws below exception when TomEE is 
> restarted with session persistence (and above bean is created during that 
> session):
> {code}
> java.lang.NullPointerException
> at 
> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:121)
> at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.readResolve(NormalScopedBeanInterceptorHandler.java:125)
> {code}
> It works fine in all Weld 2.x versions I tested so far (WF8/9/10, PY4 and 
> "plain" Tomcat8+Weld 2.3.0).
> Work around would be to use a static method on application scoped bean, but 
> this is not nice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OWB-1123) NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15398677#comment-15398677
 ] 

Leonardo Uribe commented on OWB-1123:
-

I have checked the example reported in MyFaces side and the problem is related 
to some changes in OWB. In TomEE 1.7.4 (OWB 1.2.7) it works well but in TomEE 
7.0.1 (OWB 1.6.3) it throws the exception.

It is clear rely on BeanManager serialization is not a good idea, so I fixed 
the code to avoid the serialization step and get the BeanManager using 
FacesContext, but that doesn't fix the exception at restart (it fix the one at 
shutdown). So I guess it should be something wrong in OWB 1.6.2 and upper 
versions. I can't see anything different on the stack trace.

> NPE at NormalScopeProxyFactory.createNormalScopeProxy during deserialization
> 
>
> Key: OWB-1123
> URL: https://issues.apache.org/jira/browse/OWB-1123
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: TomEE 7.0.0.M2
>Reporter: Bauke Scholtz
>Assignee: Mark Struberg
>
> Imagine a session scoped bean which has an application scoped bean injected 
> as property and it's being referenced in {{readObject()}}.
> {code}
> @SessionScoped
> public class SessionScopedBean {
> @Inject
> private ApplicationScopedBean appBean;
> private void readObject(ObjectInputStream input) throws IOException, 
> ClassNotFoundException {
> appBean.doSomething();
> }
> }
> {code}
> OWB 1.6.2 as used in TomEE 7.0.0.M2 throws below exception when TomEE is 
> restarted with session persistence (and above bean is created during that 
> session):
> {code}
> java.lang.NullPointerException
> at 
> org.apache.webbeans.proxy.NormalScopeProxyFactory.createNormalScopeProxy(NormalScopeProxyFactory.java:121)
> at 
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.readResolve(NormalScopedBeanInterceptorHandler.java:125)
> {code}
> It works fine in all Weld 2.x versions I tested so far (WF8/9/10, PY4 and 
> "plain" Tomcat8+Weld 2.3.0).
> Work around would be to use a static method on application scoped bean, but 
> this is not nice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OWB-895) BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when owb jars are deployed outside WEB-INF/lib folder

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on OWB-895:


While I was preparing the example I saw the exception is not present anymore. 
It seems there was a class conflict in the example I was trying to run, but I 
can confirm the latest snapshot looks good. You can close this issue as fixed 
or duplicate, since the original issue from this report was fixed in some point 
between OWB 1.2.0 and 1.2.1-SNAPSHOT. Thanks for the help. 

 BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when 
 owb jars are deployed outside WEB-INF/lib folder
 

 Key: OWB-895
 URL: https://issues.apache.org/jira/browse/OWB-895
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes, Injection and Lookup, Java EE 
 Integration
Affects Versions: 1.1.8
 Environment: Apache Tomee 1.5.2, OpenWebBeans 1.1.8
Reporter: Leonardo Uribe

 I have been working on the CDI extension points of MyFaces Core 2.2.x, 
 specially the part related to @ViewScoped and @FlowScoped annotations.
 The solution proposed and committed on the latest snapshot works with weld 
 and openwebbeans. But on the way, I have found a problem when I tried to 
 deploy a demo application in Tomee 1.5.2
 MyFaces jars has internally some beans that needs to be registered in CDI:
 - org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean  (deals with 
 @FlowBuilderParameter and @FlowDefinition)
 - org.apache.myfaces.flow.cdi.FlowScopeBeanHolder  (session scope bean that 
 store flow scope)
 - org.apache.myfaces.cdi.view.ViewScopeBeanHolder  (session scope bean that 
 store view scope)
 And in the classes implementing Extension you can find some code like this to 
 register the beans:
 void beforeBeanDiscovery(
 @Observes final BeforeBeanDiscovery event, BeanManager beanManager)
 {
 // Register FlowBuilderFactoryBean as a bean with CDI annotations, so 
 the system
 // can take it into account, and use it later when necessary.
 AnnotatedType flowDiscoveryHelper = 
 beanManager.createAnnotatedType(FlowBuilderFactoryBean.class);
 event.addAnnotatedType(flowDiscoveryHelper);
 }
 It works well as long as owb jars are located in WEB-INF/lib folder, but in 
 Tomee, MyFaces and OWB jars are located in tomee folder/lib . In theory the 
 code should work but it doesn't. 
 The effect is the application fails because these beans are not registered on 
 CDI environment.
 Suggestions are welcome.

--
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-895) BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when owb jars are deployed outside WEB-INF/lib folder

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on OWB-895:


I have tried with the latest snapshot and the exception is still present 
(apache-tomee-1.6.0-20130903.041125-168-webprofile.zip). I'll provide an 
example soon.

 BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when 
 owb jars are deployed outside WEB-INF/lib folder
 

 Key: OWB-895
 URL: https://issues.apache.org/jira/browse/OWB-895
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes, Injection and Lookup, Java EE 
 Integration
Affects Versions: 1.1.8
 Environment: Apache Tomee 1.5.2, OpenWebBeans 1.1.8
Reporter: Leonardo Uribe

 I have been working on the CDI extension points of MyFaces Core 2.2.x, 
 specially the part related to @ViewScoped and @FlowScoped annotations.
 The solution proposed and committed on the latest snapshot works with weld 
 and openwebbeans. But on the way, I have found a problem when I tried to 
 deploy a demo application in Tomee 1.5.2
 MyFaces jars has internally some beans that needs to be registered in CDI:
 - org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean  (deals with 
 @FlowBuilderParameter and @FlowDefinition)
 - org.apache.myfaces.flow.cdi.FlowScopeBeanHolder  (session scope bean that 
 store flow scope)
 - org.apache.myfaces.cdi.view.ViewScopeBeanHolder  (session scope bean that 
 store view scope)
 And in the classes implementing Extension you can find some code like this to 
 register the beans:
 void beforeBeanDiscovery(
 @Observes final BeforeBeanDiscovery event, BeanManager beanManager)
 {
 // Register FlowBuilderFactoryBean as a bean with CDI annotations, so 
 the system
 // can take it into account, and use it later when necessary.
 AnnotatedType flowDiscoveryHelper = 
 beanManager.createAnnotatedType(FlowBuilderFactoryBean.class);
 event.addAnnotatedType(flowDiscoveryHelper);
 }
 It works well as long as owb jars are located in WEB-INF/lib folder, but in 
 Tomee, MyFaces and OWB jars are located in tomee folder/lib . In theory the 
 code should work but it doesn't. 
 The effect is the application fails because these beans are not registered on 
 CDI environment.
 Suggestions are welcome.

--
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-895) BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when owb jars are deployed outside WEB-INF/lib folder

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on OWB-895:


Hi

I tried the latest snapshot 
(apache-tomee-1.6.0-20130823.041201-155-webprofile.zip) and the problem was 
fixed at some point between OWB 1.2.0 and 1.2.1-SNAPSHOT. But I notice another 
different problem related to the producers. Suppose this producer method:

public class SimpleFlow implements Serializable
{
@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {

Note the base class is not defined as bean. If the code is deployed, it works 
well with OWB and Weld but with Tomee configuration it throws this exception:

SEVERE: CDI Beans module deployment failed
java.lang.NullPointerException
at 
sun.reflect.annotation.AnnotationInvocationHandler.memberValueEquals(AnnotationInvocationHandler.java:233)
at 
sun.reflect.annotation.AnnotationInvocationHandler.equalsImpl(AnnotationInvocationHandler.java:204)
at 
sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:59)
at com.sun.proxy.$Proxy37.equals(Unknown Source)
at 
org.apache.webbeans.util.AnnotationUtil.isDeclaringClass(AnnotationUtil.java:68)
at 
org.apache.webbeans.util.AnnotationUtil.getDeclaringClass(AnnotationUtil.java:85)
at 
org.apache.webbeans.component.creation.BeanAttributesBuilder.defineScope(BeanAttributesBuilder.java:255)
at 
org.apache.webbeans.component.creation.BeanAttributesBuilder$AnnotatedTypeBeanAttributesBuilder.defineScope(BeanAttributesBuilder.java:505)
at 
org.apache.webbeans.component.creation.BeanAttributesBuilder.build(BeanAttributesBuilder.java:106)
at 
org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:923)
at 
org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:637)
at 
org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:567)
at 
org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:189)
at 
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:187)
at 
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:162)
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:43)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:799)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:613)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1122)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:985)
at 
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:127)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at 
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1113)
at 
org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1671)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

org.apache.openejb.OpenEJBException: Creating application failed: 
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:897)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:613)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1122)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:985)
at 
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:127)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 

[jira] [Created] (OWB-895) BeforeBeanDiscovery.addAnnotatedType() calls does not work as expected when owb jars are deployed outside WEB-INF/lib folder

[Leonardo Uribe (JIRA)]

Leonardo Uribe created OWB-895:
--

 Summary: BeforeBeanDiscovery.addAnnotatedType() calls does not 
work as expected when owb jars are deployed outside WEB-INF/lib folder
 Key: OWB-895
 URL: https://issues.apache.org/jira/browse/OWB-895
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes, Injection and Lookup, Java EE 
Integration
Affects Versions: 1.1.8
 Environment: Apache Tomee 1.5.2, OpenWebBeans 1.1.8
Reporter: Leonardo Uribe


I have been working on the CDI extension points of MyFaces Core 2.2.x, 
specially the part related to @ViewScoped and @FlowScoped annotations.

The solution proposed and committed on the latest snapshot works with weld and 
openwebbeans. But on the way, I have found a problem when I tried to deploy a 
demo application in Tomee 1.5.2

MyFaces jars has internally some beans that needs to be registered in CDI:

- org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean  (deals with 
@FlowBuilderParameter and @FlowDefinition)
- org.apache.myfaces.flow.cdi.FlowScopeBeanHolder  (session scope bean that 
store flow scope)
- org.apache.myfaces.cdi.view.ViewScopeBeanHolder  (session scope bean that 
store view scope)

And in the classes implementing Extension you can find some code like this to 
register the beans:

void beforeBeanDiscovery(
@Observes final BeforeBeanDiscovery event, BeanManager beanManager)
{
// Register FlowBuilderFactoryBean as a bean with CDI annotations, so 
the system
// can take it into account, and use it later when necessary.
AnnotatedType flowDiscoveryHelper = 
beanManager.createAnnotatedType(FlowBuilderFactoryBean.class);
event.addAnnotatedType(flowDiscoveryHelper);
}

It works well as long as owb jars are located in WEB-INF/lib folder, but in 
Tomee, MyFaces and OWB jars are located in tomee folder/lib . In theory the 
code should work but it doesn't. 

The effect is the application fails because these beans are not registered on 
CDI environment.

Suggestions are welcome.


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