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