[weld-issues] [JBoss JIRA] Commented: (WELD-846) Incorrect handling of cyclic dependencies between BeanDeploymentArchives

Dominik Sadowski (JIRA) jira-events at lists.jboss.org
Mon Feb 21 06:57:14 EST 2011


    [ https://issues.jboss.org/browse/WELD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583551#comment-12583551 ] 

Dominik Sadowski commented on WELD-846:
---------------------------------------

Is that bug really fixed?
I used weld-core build from https://issues.jboss.org/browse/WELD-859 on GF3_b43(web), and second test 'TypeVisibilityForExtensionInNonBeanArchiveTest' gives error for me:
org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]]

first test passes OK

please confirm that (eventually reopen)

> Incorrect handling of cyclic dependencies between BeanDeploymentArchives
> ------------------------------------------------------------------------
>
>                 Key: WELD-846
>                 URL: https://issues.jboss.org/browse/WELD-846
>             Project: Weld
>          Issue Type: Bug
>          Components: Resolution (Typesafe and by Name)
>    Affects Versions: 1.1.0.Final
>         Environment: GlassFish 3.1 
>            Reporter: Sivakumar Thyagarajan
>            Assignee: Stuart Douglas
>             Fix For: 1.2.0.Beta1
>
>
> 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)
> |- WEB-INF/lib/A's BDA (accessible-BDAs=WAR-BDA)
> 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. 

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


More information about the weld-issues mailing list