[jira] [Commented] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495902#comment-14495902 ] Nuno G. de M commented on DELTASPIKE-385: - Hi Gerhard, Many thanks for referring to the deltaspike-833. I will try to find a change to test the deployment against the snapshot verison. Many thanks. > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > Fix For: 0.5 > > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495784#comment-14495784 ] Gerhard Petracek commented on DELTASPIKE-385: - please have a look at the current snapshot (also see DELTASPIKE-833) > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > Fix For: 0.5 > > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495747#comment-14495747 ] Nuno G. de M commented on DELTASPIKE-385: - Hi There, The issue is flagged as resolved. However, with the latest release of detlta spike I notice the same warning messages in the application server log. In this case weblogic 12.1.2 and some bugfix patches . The application is, in this case, a war, not an EAR. I this problem a class loader related issue? The application is again since long deployed and running, but the warning stay for the duration of the deployment lifetime. Kind regards. > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > Fix For: 0.5 > > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736884#comment-13736884 ] Richard DiCroce commented on DELTASPIKE-385: I'm busy with other projects at the moment, but I'll try to carve out some time to test it later this week. > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > Fix For: 0.5 > > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- 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] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735884#comment-13735884 ] Mark Struberg commented on DELTASPIKE-385: -- Daniel, Richard, could you please try this fix and report if it works now? txs! > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > Fix For: 0.5 > > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- 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] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735883#comment-13735883 ] Mark Struberg commented on DELTASPIKE-385: -- After thinking through it I think what happened is: JBossAS boots a BeanManager for the shared EAR parts. If the extension resides in the EAR lib, which classes will get scanned? Also the ones from the WAR files? In any case, the AfterBeanValidation for the shared EAR jars seems to get triggered before the BeanManagerInfo gets created. As a fix for this situation I now check whether any parent ClassLoader has a BeanManagerInfo with a booted flag set. PS: EAR is in general a very ugly part due to the missing ClassLoader definition in the EE umbrella spec. We tried to fix this in CDI-1.1 but had to give up due to missing definitions in EE itself. See CDI-129 > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- 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] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735852#comment-13735852 ] Mark Struberg commented on DELTASPIKE-385: -- What we might try to do is that we also 'flag' parent ClassLoaders. Means checking the parentClassloader and reset the flag for them as well. My assumption is that once we get this event to some child classloader CDI Extension, then the CDI handling for the parent classpath must be finished already. > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- 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] (DELTASPIKE-385) Spurious BeanManagerProvider warnings when used in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696355#comment-13696355 ] Daniel Zwicker commented on DELTASPIKE-385: --- I was in trouble with this one, too. So i have written a small utility-class bring a workaround in place. You can find it on as gist https://gist.github.com/dzwicker/5895476 > Spurious BeanManagerProvider warnings when used in EAR > -- > > Key: DELTASPIKE-385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-385 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce >Assignee: Mark Struberg > > BeanManagerProvider spams the log with this warning, long after the container > has been started: > "When using the BeanManager to retrieve Beans before the Container is > started, non-portable behaviour results!" > The problem appears to be caused by having deltaspike-core-api in the EAR > /lib directory and using BeanManagerProvider from inside a WAR module. The > warning gets printed when the booted flag for the appropriate BeanManagerInfo > is false, and BeanManagerInfo instances initialize it to false when they are > created. The only place the booted flag gets changed to true is in > cleanupFinalBeanManagers(), which iterates over all the BeanManagerInfo > instances that exist at the time it is called. > In my case, the only BeanManagerInfo that exists when > cleanupFinalBeanManagers() is called is the one that was created when the > setBeanManager() observer method was called by the container. But the > classloader in use when setBeanManager() was called was the classloader for > the entire EAR. Because I don't attempt to use BeanManagerProvider until > after cleanupFinalBeanManagers() is called, this means that the > BeanManagerInfo for the WAR classloader is created with the booted flag set > to false (which is incorrect) and the flag is never changed to true. -- 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
