-
Bug
-
Resolution: Done
-
Major
-
1.1.0.Final
-
None
This issue occurs in GlassFish with the scenarios discussed in http://java.net/jira/browse/GLASSFISH-15735 and http://java.net/jira/browse/GLASSFISH-15721 when GlassFish provides BDA hierarchies where there are cyclic dependencies between constituent BDAs.
While constructing BeanDeployments for the deployed BDA in in WeldBootstrap.DeploymentVisitor, and visiting the tree of BDAs, the code appears to incorrectly check for seenBeanDeploymentArchives for adding accessibleBeanManagers for a child BDA.
GlassFish uses the following BDA hierarchy for a WAR with a bundled library (WEB-INF/lib/*.jar):
WAR-BDA (accessible-BDAs=WEB-INF/lib/A)
|
In WeldBootstrap.DeploymentVisitor.visit(...)
-. initial invocation:
managerAwareBeanDeploymentArchives and seenBeanDeploymentArchives are populated with WAR-BDA
- - then as part of the WAR-BDA's getBeanDeploymentArchives loop:
- - - visiting WEB-INF/lib/A's BDA
managerAwareBeanDeploymentArchives and seenBeanDeploymentArchives are now populated with WAR-BDA and WEB-INF/lib/A's BDA - - - - then as part of the WEB-INF/lib/A's getBeanDeploymentArchives loop:
- - - - - WAR BDA is an accessible BDA of WEB-INF/lib/A BDA. However since WAR BDA is in seenBeanDeploymentArchives, WAR-BDA is never added as an accessible BeanManager of WEB-INF/lib/A's BDA
This prevents Beans from WAR BDA being available in the WEB-INF/lib BDA though it is included as an accessible BDA.